“Calhoun 


Institutional Archive of the Naval Postgraduate School 





Calhoun: The NPS Institutional Archive 
DSpace Repository 


Theses and Dissertations l. Thesis and Dissertation Collection, all items 


1987-03 


A data base design for a multimedia C2 
workstation in support of RESA 


Carroll, Michael F. 


http://hdl.handle.net/10945/22719 


Downloaded from NPS Archive: Calhoun 


Calhoun is the Naval Postgraduate School's public access digital repository for 
D U DLEY research materials and institutional publications created by the NPS community. 
qe Calhoun is named for Professor of Mathematics Guy K. Calhoun, NPS's first 
KNOX appointed — and published — scholarly author. 





LIBRARY Dudley Knox Library / Naval Postgraduate School 
411 Dyer Road / 1 University Circle 


http://www.nps.edu/librany Monterey, California USA 93943 


e 


۰ s DR 
be 
a D 
, 
LI 
k] LJ 
D a, 
LJ P 7 
EA 
D ۰ 7 
D D e 
4 i 
a, LA 
. 1 , 
Li ` ‘ "T 
H * wv H 
2 ۰ 
- a LR H 
» H WI 
5 a D r 
UR RI LJ 
ki 
>=» e». 
n "n 
"t D LJ 
H y y 
D H m 7 a 
LI * 
" 
LI A 
. H ۰ n D 
E " D D 
D E 4 
D 7 
a L 
E 
H ^ 
D H 
. H n 
M H 
D 
a 
a an ۰ 
D 
a L 
ta Li 
H 
HU 
LI H 
D 
H H 
' H روف‎ 
H a e 
* 
WI 
" 
^ * sr 
" ۰ 
c H H ۰ 
1 l 
۰ D e 
E 
۰ 
D 
D 
D اشيا‎ 
.. 
M » 
E 
۰ H 
E " 
H a 
“ 
E A 
LIP 
D D 
E 
R E 
D 
D 
D 
D 
LI 
D 
LI 
* 
D 
D 
* ^" 
D 
E 
D 
U 
H D 
H 
. 
۰ 
۰ 
D 
H 
۰ ka 
e 
H M 
4 
E 
D H 
# 
D D 
LN] 
H HU 
E 
D "En 
۰ 
D 
E 
0 
D a 
D ۰ 
H 
D 
" vo 
$ a 
٠ 
"a * 
m 
D 
LI 
LI H ` 
D " E 
D 
D 
H i H 
n E 
D 1 
D D t 
D "D 
H 
D D 
D 
E 
a E 
۲ 
D 
E 
e. * 
E 
LI 
D 
Ce 
H 
y 
e 
۰ H 
D 
H 
0 E 
D 
D 
D D 
D ^ E 
a LET 
5 D LI 
L] 
D 
۰ 
. LE 0 


Dee MER‏ سڈ E E yey ys Moet on‏ ریت ES A‏ یک سم a Eat, A Mere‏ سو 

Y EMI PA KEEN EECHER OR RA EE LAN Yo aa api tad Ch an de aa desin a an e tes ee EE ET utili d 
L | bi pa STE lei "ww XI v IP ٦ 

wie wy DAP Y 


a V od 
Kad 4 ا با‎ 


i ال‎ 
٠ ٭ فيه‎ ep 


(RAR A 
تر ےدک شما‎ 


Ls p Yi ES OTER Y Min lé bell den, Aen RTT‏ دم 
esr e Icio ed te PE PTT‏ ہم وکا 8 a PP TN A E "NA yt Lege‏ 


dt ri ame) 2 , 11 چا رک ؤ۰‎ dre ig تچ‎ PE E O E a yey fo ray gr ap VT hy mp ا سز‎ 
AN : M e ML LII KN d ih ttt ed ad (4448.4 ومجوعف ھ ھر ہر ھی ھب‎ Ne ا‎ 
CN A ATA RANA Ad yon CN uA. Code ia GË? SR LA RES 
d t یچ ےی ی وو سس نشی بن یں سيا ہ زی یز و ی چ ا ی وی رة‎ ^ EEE EZE E E E e a) 
D DICE E رو‎ 4 d ws Did dd E AA e ۰4 ایل بم‎ te pe aaa pa Uo AS Rt nu 
. D A Y AA IA ACA 00 4 IA GA نیا بل ویر ہوا‎ Rd n tne ro do tat, 
A A TO ا‎ de a ا ریہ ٹر نٹ نہ‎ m EE OTE D 
4 SA Y LEE E EE eae OTT WO KC EH Aft کے‎ p omes. 
١ TE Phe A ern MET LEER WS رہ رٹ‎ RA AE So oF Ne de api. M TS (ag er ELE 
D Ter .ہا‎ esie E EE A d e 
e DE ALÉ 





ad EE 


SA)‏ سرت 





se ër deër m 2 rne Pr. re ee alee gad A dari ud ech 
Fae Bal es We ay dy SM tel, d TET M etre "T 


a. DE Jb tot C جھعد وو عید موک‎ EN 
VD Bos a ni de. ai e kai DD ty egi lapey a AT V NER PECES mU T m TI es 
JG PCIe SEI میٹ‎ pc ا رہ رر‎ rm APR er n 

RN E A A TEA TEES LÉI SET E EE ene pg 


ae A EE Pi RA UNS mah‏ رس رر ہے سور ہہ و رر رر ٹک 
یہ (seit KE‏ رے Meri KEEN‏ شس ھی رب ہے بل بد pe ge‏ 
رر 
ka‏ 











3 pen 

m 4 mv fec ANA TATE E ¿NA > AA ہی‎ 
" ۰ sa E NE T TC Wm mare punire a e A 

E » D n HL La SS TNS E اک‎ DN uel oun ki یہ رنہ یں‎ nî BM Û یہ‎ 


$ l ۱۰۰ر وج“ ہیی ہرم ہی‎ € nen D. 9 TAR DA whe YET 





"یس 


be Bronce 


Py Wi. TTESY a4 DN SCT E EE ET m EE ER yo aeq Kata WR s el afe adii رج مہ ری‎ ۹> 027806 


"m a iN ^ 


DT 
5 ید‎ wi 1 se ا‎ 


` y D DESCH A TL DE EE m] 0911 


۹ ہے رجہ‎ ZE? | le verry n "nui 


LEM r 
DO ELW 
vo D 4 Ki 
" Ié 
sins 
4 06 
D E “passah 


Ki 
LEES 
E 


a 
و‎ 


"n NET A a RAN E PR Weg پا‎ "ev 


e e A e b nag he 





LÀ 
sa» © 
D 
0 
1 
D 
a 


H 2 rio E Meet h^ doo 4, ا سې ی دمام جد‎ eT AD مم سس تبره هو غه مد‎ DU netar iggy 
" Al» LC DAL رز ہا‎ e iua Lo TP WWE UT PN ETT eee | ood uuum. yt 


4 vi A4 M, ,۱۷ ۸×س ۹ہ چد عث‎ ET eee ee ée A a ۰ق وھ شب‎ ef oh led esa quo E kap en e fas > 


ai ss qw sè piy LA eres Les "p e RA 
A ° ¢ مقد:‎ f angst ett nolan. mus یں‎ mo aa bat. اذھ‎ po م-‎ 
KS © tea DID eee AAA Hors eres, po adage T لس‎ E و‎ ep evra: mesa Zp 
eram am 


gi M Lu کہ اس دم اپب ری سیر نے‎ rrr": سس یا‎ m Lige Zen ET EE 
جوف یں‎ ET EC ECK er et Cen Dt e E EH wp SS ern 
DEER ina a مد‎ Ee A a 
EEN 


A Ae Son cq ATionc eU Nard ia; 0ھ ۶و یر‎ 
"TEC II eee pi BAS کڈ‎ m pe A ponn او سے‎ TETE NT Wi EE 
OSCH SW fh GË eg NERT E C mieten Kache وٹ تی اکر سور سور ںا‎ pò ¿MÁ mat rA $c cd EE Ee 
Oe eee ee Ce SARNA TANTRA Te eee ts لے‎ dipende 
ےت‎ CRUS proie IAT A TE SET RORO TE ieee دا هھ‎ pwa سس تھسا وچ وھ‎ 
۳٣ ورپ وة 7 .رر‎ 0 Ze Se, A ^» dab e oo " LT mu: Door 
ef EU DO WC E سام ال ہو‎ EID regie vay GN “a tes a èn Lieder ste سد متس و‎ 


mar Ad‏ یج مم 
e? e Kee KE tech eng RENE P‏ دن Ld eee nd ana tel‏ سعمد 
TTL E p. * etw street c. ET ET E Y TRAS peg jen ki Medias De‏ 

D ta Pi ےہ‎ IA SW E dè at deg BACK d Vid Adan n IR AN LM TA t. بے‎ mom Eed don n Pa an 
D 1.24 €. 05 oe af Atte? Target. = ete NE ei 04 eck H? wa GE شع اگم ف مو‎ dese banal PES 
A (E OT TARTA] eer ws ae nia 1j. 4 E zin. TELLS بج مم‎ E ya 
اج‎ DAN " “enn teg ا‎ A EA $ Co 220 GA ite A M. sso Lag: wa rana w rit qp eng A 
اک‎ D D ۰ en ce PLN ur ^en hot n dE EA aret ap: as des 

YA YONN A y Kee A V M " ag ہیں ںی‎ ue i EPS Fr ae H Garer reste? 
A AITANA ati: Bo ae a e TP ZR CD eee ee 
n PA NA MASA I LIS A 8 e T EI نو‎ Anl e EE epic Afra dtt Zeg drei 
عم (ھ ۸۵9ا‎ IN ا و ہی لے نیچ‎ Lu uode Rss d 
UE TU wo; c رر و‎ hon no ALAS Sa. ۳ TEAM TTA ٦ Pes Taide A e apes PIRE P E E TEE کپ ود رد‎ 
Mary DEEP BCEE ate Pv e Ed KEE DT EE OT E E PEE n e 
DPI) ape ao raté تی ےر ہز رر یں‎ + GI A» Ned (werden TORS. mee) ecd A o * uberi auod A paar ut pag ہر کے‎ 


Ah‏ ند مسسدنا 
i 5 PTT MEE ELTON NATA Aya Als a) Se TTT E a H LR NEE ER‏ 
ماس EU AA dr e A D M Zë Set Ee E‏ پر ری اہ بی ce: vi‏ ما 
i reg‏ 


D مت‎ ama: 
A EP ane ار تر رڈ‎ "T MTM O PO YO Se Zä: Ger area DCH d EE UE EE TR 
PT als, < ٠ پا لہ‎ wi ET E Y ی ا‎ d Fur ey ور‎ WIR EECH Fue a 
ay YA am ou, WH ےا م‎ E A ese Ke Eet y 5 
3 ur e 


E 
d CT) "d ye “Pi Sa PAT of ea 
LAI AAA e e o 
n: "tem f 







E 
“he 


اپ 
ti‏ 
lè.‏ 


g 
a 













IA ET A mde. DEEN و‎ : Dane AARIN aa ¿dd 
۰ tase (KT OT RECHNEN A ¿dar is RT E e" DS 
Teen à « ER E wx کرام میم ا الا ری میں‎ CS DD pos sica lr 
a on (OO ہد‎ TOS Deag? ee eec ebrei onde P 
X داو ص ییا‎ FAP DE É سے پ سیا‎ E LA تی‎ a a a تر بی پیر‎ 
W EAS qct a bin bie Ben PS I rd 1 
CES v" (QA P EL PT / Kec Lin Fr ad pro Wed eT ` 2 
EL" E O: eri نف‎ An e «a و رٹ ہس سی ہج‎ 
DI DESEN D جے‎ D Geh Y ای مج‎ ous ly iet UE pda 
Lm و‎ ig mE E a: jada er cit quce ps ^o he tee eaten 






sat a > y 4 ETE Á Tid de شڈ‎ aki ۷ ا بل‎ ST TAY Eelere T 


i D | EE LA Wi L me V eee qa 5 re 1 VO A ET DYE Zo NE DO TA ao hd 
لاٹ‎ 4 Av e ai Pow A Aa ` m NC We Kai d at ا‎ EE tiem or a بش جج چا‎ PR PO rare ee RET 


E r 1 he RS AS ye DT رر وف‎ ras D EE KEE 
My انپا‎ $ € AA ور‎ os تس موی پور وتونلو یہ‎ ance tos Lakes کچل میں‎ s یتسہ‎ e rd - 
D 


` a, EH RAR Y ae ON M goes 2" e RE Al HS وأ‎ Sere eee 
E S 2 ES > ze e ee E epos Eer Se Cie ہا‎ m sl Tj pm qe. e dri ge sA RE سط‎ 
۹ Wei 1 e KEE ARE "T RE HE is «A Ger یں‎ gem ba van eg EE [AO e 
* an. Al» VS Ae ab rer II La ya Y bi, A -—— a کہ‎ 
elt Ke CNN e کات نک کش یں ہیں ہیں‎ ma ak ege DCS KEE re Dosa sye di a ee i cee a ah eae Sm 
ERI 1 ah And sa, = در‎ bh DEER و‎ vilaj a and e ںا ےر و یں کر شور سید‎ E جو یں سس کے ایت کا وی سج‎ 
ارام می‎ di ie ضر دید * اس بر‎ ap sèd پوپ ہس‎ E ka be pi A Mi I Mi زذ اہم ےم ہی سر یں مم ای دک‎ ee a 
مار کور جال یں‎ v ride See? DN Ee en E ee ed E 
" ER ET 7 PE NS rdi. a be ہد ںا و‎ B ا‎ Aa et delt, BEA Ee e RA? heen be weer aed DIU any 
"S mu RE? se poi” 4 she He gro ld CA men are. Ca ARA - deeg Eer EE 
pa” rw p م کھیسے مود و‎ Aen ar Mier) pat eats no EE کرد‎ ah E X ue bi Ken ER E 
7 ای‎ PR S0 #e E 7 بے یں یو لو‎ d Lë? La EN Lat dd KH a e aran bac idea 
` e pi r OY D AS 6 ا‎ LM DE SECH, A swa o qe 

s EI 


4n 
موب‎ s لی‎ e e E CN peer hee 
LE ds E ` 
RE 
Seu > 



















sa 2 
a 


= [E] HEU Ae 
A a YON rt EE d EECH EM Pm 
Sd mo “pb یں‎ Vie AE ETUDE TO TE 
٠ LS ELI E PIT وی جا دا‎ RM 
P IET SEED کل‎ dE 
















Pi MAN YÉ kri ster mi 5 ie‏ 2ص 

"A ETE" wx eT eue "b aif jn PA ٠ Fy kay |e pitie KA apab boue 

Ls ea de "frein ap (aber SC" 

+4 i D nm "EP. ا پت‎ YOUN IEEE Me Silene re ti A Ser? m pe 
ZR TIME PPP KT رن‎ TS 5 So tape 

t “Si AM T E: 0-2-9 E D pua ee a rt etai ar EN Wé? GR ang 


" KW a CITE O O یں‎ Son ` ہمہ‎ a 
EVE TE Tee E EE MN E ORE S ION fe t A E XA UU ës 
DE ML" EO یں ہر‎ PETAT M dude éd v. a AP PEDE Sr Gm ¡A aes 
ا و ا یہ یس‎ AS ex iS na dl ات‎ ei PRO پل یر یں‎ GEE e 
PAR a D ER m carer ay ٦ c 
r, یں‎ 
Tus Wo 






























D 
3 
$ 









P E T^ 
Da AR Rb. 


a ies 


و 
t] E‏ > .9 
بیو 


pi d 
یم‎ 6 1 F, 





E 
02 
NU 
شی‎ 


d 
7 





2 
E 
b ab 














LJ 

LA 

Ki 
Af? 


A 
d 
0 
^ 0 






یکس 
H‏ 

` 

A. 

A 

md 

و 

* D 
A " 


5 
NE 
TATE, 
EE A 









EE 
2; 
Apa nn عم‎ SES x hg 
imt, e 


REO efe A A 
کمچ سی تو یک‎ en ےد میم‎ 
سی چ تاس ود و وچہ عحدت شا‎ 





, ri * 
m . - m : d qa A 
L im E پر رت ہن۷ تمہ‎ 
م کو‎ Ke ره و‎ ECH SÉ 
d fe ELL KSE CW 
4 e ب ا و‎ gen A * y 
AIV ED y penn. H D 

WA PE E E M ET و‎ ۰۴ KN? 
hd Li 4 و‎ ar پر‎ VK ایم‎ 174 Fi +e" 

1 d d Bi t .. T £ " EN A kat H ٤ S 
PEST ei "TI £ TA t 
Li Yn a D D 5. PAD FO l 
wo e E. * 1 en.” | 

e 4 D D e fo. 17. *. 
L a PL Vè "IL F3 
vot 






















n 
art E 
Sp oe, . > T" PN 
e, m CS M E 
PP ہہ‎ E EA D bos KA A ipd و سم ےل 8 ا‎ Sa oue dct d HO rm 
E Y Renee Ea NG LE SOE سر ار می جر ف‎ 
P ain 1 e A HEH Md 429 A ap p d LEM dbi rd 
D EE fate c tant Wé SCH e I- ad Li " rA Tl بک سا‎ 
JEN rM 
p lant mini ہب جب‎ 
e Ze eme ee mi 





ahs War ae reat ge meet eee 
ےب‎ ad Dl a pimp esè LP "ig sec d 
n > - KH Rm done چا یب‎ 

LT چر یں ےا‎ nan ید جم حر سے سر با یہ نی‎ on Ge 





































- D [ Oo sie a es pt 2 KK: : 
a VW = "y NA, اس‎ om ee” to. 
Ah وم‎ HY: ٹر وب‎ CE ری‎ yo Ce PT 
7 Ir "TTE وا زی‎ e - oc WA KS di e HT Id 
. rg afe o P ےج‎ s DIIS Kä e A ré Të e Du KÉ Nk ` 
DER os £ uL ha a LA HEI P LEE ag lee کہ‎ q 
P a "d g> رہ یں‎ Lecta ae 
E LH T SE 


W^ Od na NA ow d diu ath REI 
4 1 D z IL کی‎ Käre P 
ne 7 ننس‎ ar eoru ui ti E D E mp 

dé تد و اوخ او پت‎ ACIE e 
$ Agen ia TEE ہے تا یں‎ geg 
oe west سیت‎ ipa od mm 
m Së a H DEE beach éen age a کے بس‎ 
000 مه‎ «Udo ac iu CL cta LEM p 
H Fi Ld 

HM SZ CEET ET 
E E Zones ud poem ESL 4p re ate 
سس انوس‎ E s eie i EE FE te I poen i a e E a 
2 A3 sch) SE ¿TU al جس ےرہ‎ 











rS 










OA a Ee gie ch 
7 "TE بب زیر‎ go د‎ ° 


E 
KN DN A ki UR EA H 
q E H 4 5 ny y 
" e IT "EGET 


PR $e‏ فو ہم 
ks ant?‏ 
















E 
LC Ari uh. J e UL D خر‎ 
ver Pp, E TT Beer meh o UE 
را درا‎ ML bil ee? TE EK Se dono a 
D H PM Pp KA 
DELPB TA a de aki ہی‎ ee aoe eee ki Ere UNS. 
D H TA ET VI I ے27‎ ١ ١ ز۔‎ BAR OM TE E چا نے‎ "TM 
L] " . 5.4 a : “go e á wë Kaz Tou ini da dw E E 
D CRW رر‎ + . rh NOE AR AA hd نپ‎ 
" Or lo we A 3و0‎ E و ول سی‎ E LP 0 : H AP E te EE Co, ior: d e mt e qa 
> a Wo ! A No ome or DELT e RE EE E ones SERA chs DEE po pu i Ni cioe سوا‎ cu ud Amo tray 
NECI. | A E MAACH aa E Ua AA PP ra ZE Lo e Segre dS 
ie i 1 aa ro r aro»? Ke £o (x AAT "te "em و‎ Lo ai EAS Visite dl امت‎ Ae Mami un caa: سو رو‎ 
بد ا ا‎ y oa ge 5 PA roy TT E mtem ihe ZE Rt qnt mic arg 
. mb, A TT D A Tl IS DETTA d LS mou 6 Ki SP ced Kine SpA Al ocr ké a n ajan لی مہ‎ 

D "EJ TAE ILE LIIFLD ate ED UP a Dé gp At n ae A UN uie m ome d ces Andria eater P TE eg gh e UA 
we تر و رجہ یں ید‎ A < + wd E ey ta ا‎ Sin ten Dm du mam m E EE pares 
4 me — w a PW TO OR ری‎ . a eT P a dO Pn a ور یا یں‎ e al ki LIP Ke EN a aE i 
ehy D m LIP D ۰ D Ca ید ہیں | ھ٣ سو رب و ےب مج‎ sg ar rat p رس‎ A A A ye وی‎ EE 
0 El ee Ye o, © A ق وي و‎ E TD TT PS ka it, n et re toii ed xê Te ae کبس‎ 
D PE (RK in ALT ور‎ 1. opos mps DT aki E ald نس‎ EE EE 
cogo XX 2 LAN ےر یا اراس‎ diven WË Ln پر‎ DG WK its rr terry FL A dit ae EES ET ege 
۰ 2 ا‎ a a پیل‎ wig uiga یی ار رو شس میق‎ gaa E konte dè pi PRA doi kib e DAN Man Cat adeleg NS age ا‎ 
n $e 0 n DEM ML Md tL ELEM LI EP LET ںا یر ری‎ qam n E di Di o hence kenge 
۰ D (GA AA n 5 Ls gi? ac LE a رو‎ Learn pert Seater dich VO Ti am kk ni, eta لہ ایی یی ی یی ای ی دا ی ا ی یی‎ 
1 L^ TIED rn deg A پر ہے ضر ص ازجا ا‎ DL $ We DTD EE EE 
p or p x 12 4 ITEM EP farsa ur رر رر رہ‎ pr ren radar o: mondi UL a a ges re ld PUNA O 
H DEST mo kk Yo. LOU E CC E A aa ki ki Ye m DEE eer ee ii RE gt DE EPE 
یف‎ ٦ " A ayi a w nje ira Vena mw ULNIS SIME LII iu سر‎ o mps re Mä EE Pelt 
"PT , پمتا ھمہ‎ TT" a Tem ot to LK: <a s مرک‎ uke cire om Th YAT, y miz, IPS ada 

e- d A » teo یر‎ do^ Ima, rw m A ka AAA Rua EEN TIT a ws ER d Dette Aide in hs a aie re dich ah سم مینسی‎ 
D P A wus با کے انا دح فور سی ہے یی یں‎ AA یں نی‎ eroe dnx one امہ وو دک ھت‎ m بے بے ۔۔۔ بی یں‎ 
yT Dn LO رر رر یں پیر وس رر دی ربا یں شی رد بس ری‎ E E چو‎ pti a hd ا۷٦ ٭صدع‎ engt dg Ae ias P ie rel acta 
E TO IS TE A RI Vr pi? رر میں‎ cr e e A na ai e 4 E iis € کے ےج جج‎ 
D ` EE o do A AAA SS onus bid Ee 
H EXIL E A EFIE P dii eme A ene Pr eee End page pr Ni pann! TE E mg 
ra D t PEO E a di KA o M | 0 di A یی و‎ een Dil ب ووی و وی ی‎ 
DN Mag a ELLA ےب دض چیم‎ giel اس یندا تچ چو نکیل او نے تی‎ Leieren o o cs el ias as 

H Bo (a KE OU WC e lge hat ابی ہے ای رف‎ M'a evite A A wa Pisa E 

Ln Lo D بی‎ Wa B onu yat dl eekleg IP iai echado did ر کی ہے مس‎ Er Fraë pe get E it 
ome €-a a. Px n Aen LE BON) on رہف‎ E ا ا‎ d eir gétt ent d eegen i aaia 
D a n Pedes زیر‎ ? Di a dad vise رین‎ Di Pe oh te ts al ae oneal rad di datio kd ead d ET EE ET ge 
H kB LM ہنی‎ nm سب‎ er Ree LDS T کر‎ Ee dioe i aaa جت‎ A Don 
e vo DW اا ا و‎ UR E ELTE IE TN RA A a esie a o RI و‎ bir a 

a "X E MEE RA Y ATACÓ DA de e VM ut Te ECK CTT s bei iain TE dg Pet ae” 


































a7 8 "€ d uet e ETAT DLS tie ath OU pem gtu A nE T a a e aaide ieas 


ki A DY n katon ank Jiska se AA yn ik vèt et aksan bal a tipa bi ri 
ai ae e د او ور‎ RE TE geg 
b Te Vw je ELM LIII ILL E oye: Oen یمج ین ری کھ ہے یی‎ 
تر یہب را کہ‎ ef H 30۷۳ ۱ یاد ا و ایی یی ا ا یا اا یر د ج۳ مو -٭٭‎ nimius inei ol EX A karèt 
DA O A A rd o A il da AAA beer 
ve A VV GR TEM D tel hoe alt gene ad dine s 
DN ir e و‎ a aes aR eme. MP e 
LIN ML | Pom Va gent REL ALS o ty aet alt WA tms ane adi boi د‎ neko LE ind. AA E AEE A AAE 
CAT ETT AR le AN ریم‎ ey TE EN (E 4° dg «ope Mop deeg A A ا سر‎ E ala a 
۰ np EP Pp UT peaked ko Pie ka ete eat Pl ka ra 
یرٹ کر جو و ۵۵۰۰۱۷۸ ۱۳۹ وے۔ یو ویج‎ AC oe, nt A aal A Mis. a ela 
eher Te eh? TO dä PN sk V LI Prè رووا‎ end sin Ci aes یدن‎ MI p ste hehe eg 
tuys Sere Yi Se EE 39ر ×وبوچی رجب رد -- نوج بح‎ )۹ Pla لی‎ ed ol ned kè vè Aen A ےرک‎ 
وو‎ rm | LE دیب یدو ی دادو ی ا ا ای دا‎ Ve A 15. ۰ مو و از با کے وسور یی‎ Pg d 
NEN EET IL Dor er ie Senet ee ote) fete Ut ee ee رر یں‎ Ae eeh n A km An کی‎ 
TS A E مانب‎ Hee Wl wy A ad PT SS da 
IND A I TT DE L یہن یش رر وسر رر و نر‎ E pea dp cdo KEE TN Ya ki had ath det al LP atk, VF e FR e Lord deae cited ihe etenn EPPA 
لم‎ DOE MA vg 8» 4 eu s VT A ای‎ eee eats سیر جو با‎ ak eebe. erc npa cn didis 
a! , ` L LEN LET a EE E ا رر نو یں رر رر ری یں کت‎ TE st 
a. B Leur “ v we Tis e pere tn n PS OD DET A ر رو ای وسک ایریا ہہ و واو ر اکھد اھ چا‎ 
TY "us MN A یں یں‎ ie AA لو ا‎ Ae cie qui ar des Kee e a cdo dobla 
" LZ یی‎ A COSTA UR AO Eet CG Lu Kelt Meng A ml Lal e ia A A A dida E cda aa حوور‎ rir Pa E bis 
D Nr We: PRSETER a ati e dir ra Pd Heer aciei a en 
c LB VI "A Ben dii X, E E ELEME REL IP EC is atado جو ردر‎ is a واج یلا‎ o ri 
"n و‎ d UR ab M A a ela) liked re 8 او یو یی ر چ ا یی ی رای ی ی ی یی د کی یت یا یوی‎ 
٦ E LA E میں ہہ وو‎ E lod EE RII dili ا راب‎ RT ie ete maa 
Fro S E D tert un CDOS BLL 2 رز و پر رر ہر سس‎ NITE بی‎ E VEH E ا‎ A A E is 
bi D EC WON ai ri l deba نے می ہے ا یں رم یت یں نیڈ شس یر ٹیر‎ prenait P tob iss 
"nm Y Lo tet sap m a KM: lis di das das A e I a a a aa ووو‎ 
at as (ECO UTC A DEE IM AO e Lee ad ENER VEH TTT EE e Ais 
Wi DKW YE EE Ch een a یب یھو یی ین یدو ن ی وی وھ چ یی وو یکی درل دا ااا ہیں ۰-9 یزرو پر ری( ہیں‎ 
= Wë te می و الا ہے‎ Oa os Ca Jos a aa 6 PILYE AA SSA DR yn IN NA Mere wegl er kaa aa KT پ‎ 
pe, m CET SML LE ALL ERA dai یی‎ Ro ee Gen KL e eta lation Ghee ue rier و ھپ کیت ی‎ TE 
+ > m ane a بے سر رج ہک‎ - PU St enr انیٹ پملنیگڈزفریرں‎ ke ا رر‎ LO IR M Leia aui e ed Mei Mina 
Tei ki ا ا بہت ا‎ eM Sra EE کا ا‎ E E a e deet uiuis a aperi 
TU » 15 qx $9) * I . 9A] 594 e BE ا رر رو میا یداو‎ LTEM ao apod ا ا ا سو‎ NTE UrV a? uro Ca Spe ah eat سی‎ 
CHEN CHECK KG T en eee is di ADAE abd eig de doc da Lo ir dd bate abate neta doer, bh ht a ا ایت و یی‎ 
۶۶ کٹ‎ DD q "We 4 m Aaa ہک‎ a a anaa ix Li La end dit Sila یدیا خف یپ‎ rd cb 
y OL IPC RM RE Meal پیک یاو‎ a oir Sa ge da ai m ipte triti itineri i torti dade. a 
TI a an d. ELTE" 4 Tih alpha baa AN رسپ‎ Ve e Ke ch edo ET LE tet Macs coge va^ gU. و تب شر‎ iie A10) ^a p VP 
e. Paw % «oe FF ۰ STT CET EN A ہہ شر‎ EC اہین ہر‎ REEL 
1 " " F INTEL TISSU یتوہ تی رہ ریس‎ Woar A بت‎ d bot dett wa A pè a padan oua 


E ۰ D EU KEE رڈ ہر رہ‎ a رر کی ور‎ Hp adored NM TK ا‎ fM ua pA TM gegen 
i DE en EE EC WC Ed MT A DEE eh Geier det a ee ee: 
(E E ET GIE RO یں .رہ‎ Sv ort) ایی رر رر ہیں‎ on و یی یوی و‎ lab Aaa rt doi apiid 








H {f L] ۴ وت ہس‎ A. m Sue Ce » ja a fet E, Me lave 
Yo 0 $ eh w ou "D 

D fa ۰ H "T 

v [4 D EJ [71 PO] 
P D v D A 7 

LL TS TT 

ff s ور‎ 


































A لس‎ ¿> a ch tuee Äer. KK eT اج لوا ہے‎ o EE ans E eee La ria 


J الو‎ DE E E E E ii A س اھات یہی کدی ی ی ی تی وو‎ cut Pid mM 

" R 1 Ki zk se, EU ad لپ یں م ا‎ af S ars ve Sie dan n pp A yy po EE e 1 
۰ ° مرو‎ ۵ DÉI ` M GT E EK a. yo. are’ TE E E لت‎ 

ھی یا dam OTO TO‏ مب سح مسا للہا دج اد کو ج سے پریڈیر جیتں در Y > A pa v VE P =: Cé MV D D‏ 4 0 

“a, “yo 005 جج‎ DDS FP os VN AT اب وا‎ = utd, KE er E E A aai 


E E‏ سی کسر ہہ .رص ۸ے 














ME 


NAVAL POSTGRADUATE SCHOOL 


Monterey, California 





THESIS 


A DATA BASE DESIGN 
FOR A MULTIMEDIA C2 WORKSTATION 
IN SUPPORT OF RESA 
by 


Michael F. Carroll 


March 1987 


Thesis Advisor J. S. Stewart II 





Approved for public release; distribution is unlimited. 





REPORT DOCUMENTATION PAGE 


ta REPORT SECURITY CLASSIFICATION 1b RESTRICTIVE MARKINGS 
UNCLASSIFIED 


la SECURITY CLASSIFICATION AUTHORITY J OISTRIBUTION/ AVAILABILITY OF REPORT 


Approved for public release; 
distribution is unlimited. 
4 PERFORMING ORGANIZATION REPORT NUMBER(S) S MONITORING ORGANIZATION REPORT NUMBER(S) 


jb DECLASSIFICATION / DOWNGRADING SCHEDULE 


6b OFFICE SYMBOL 
(!f applicable) 


Naval Postgraduate School| Code 55 


à NAME OF PERFORMING ORGANIZATION Ja NAME OF MONITORING ORGANIZATION 






Naval Postgraduate School 


< ADDRESS (Cry. State. and ZIP Code) 7b ADDRESS (City, State, and ZIP Code) 
Monterey, California 93943-5000 Monterey, California 93943-5000 
la NAME OF FUNDING: SPONSORING 80 OFFICE SYMBOL 9 PROCUREMENT INSTRUMENT IDENTIFICATION NUMBER 


ORGANIZATION (if applicable) 





€ ADDRESS (City. State, ard ZIP Cove) 10 SOURCE Of FUNDING NUMBERS 


PROGRAM PRO;ECT TASK WORK UNIT 
ELEMENT NO NO NO ACCESS.O' NO 





! F TLE (include Security Classification) 


™ DATA BASE DESIGN FOR A MULTIMEDIA C2 WORKSTATION IN SUPPORT OF RESA 


? PERSONA. AUTHORIS) 
Michael F. Carroll 
SS OE REDOR? : 135 TIVE COWERED 14 OATE OF REPORT (Year, Month Oay) FS PAGE COUNT 
Master's Thesis WOO. March oy 





FROM | 


5 SLFPLE'VENTARY NOTAT:ON 





4 COSAT: COOES 


FELD $U8-GROUP 


18 SUBJECT TERMS (Continue on reverse if necessary and identify by block number) 
Decision Support System, Relational Data Base 


Po [| Î Design, C?, Semantic Data Model, Data Base 
| | | Management System (ORACLE) 


) ABSTRACT (Continue on reverse if necessary and identify by block number) 











This thesis supports the Naval Postgraduate School's (NPS) program to develop a 
multimedia (text, voice, graphics) command and control (C2) workstation as a Decision 
Support System to aid players of the Research, Evaluation, and Systems Analysis (RESA 
facility. RESA is a. Naval wargame that focuses on the battle group/force leve 
operations and command and control decision-making. NPS will interface this 
workstation with the wargame to provide players the capability to access and analyze 
MEE. data in order to improve their decision-making ability. The objective of this 

hesis is to design a data base for the C2 workstation using data extracted from the 

game blackboard. The design will consist of a Semantic Data Model for the logical 
representation of the data and a relational data base design implemented on the ORACLE 
Data Base Management System (DBMS). This design provides a detailed specification of 
the data base structure and is intended to be used during implementation of the DBMS 
on the workstation. | 


) OS"R'3UTION/ AVAILABILITY OF ABSTRACT 21 ABSTRACT SECURITY CLASSIFICATION 
MQ GNCLASSIFIEDMUNUMITED [J SAME as RPT O DTIC users Unclassified ۱ 


a MAME OF RESPONSIBLE iMOIVIOUAL 22b TELEPHONE (include Area Code) | 22¢ OFFICE SYMBOL 
CDR Joseph S. Stewart II 2493 Code 55St 
D) FORM 1473,34 VAR 93 APR edition may be used until exnausted SECURITY CLASSIFICATION OF THIS PAGE 


All other editions ere obsolete 


1 


Approved for public release; distribution 1s unlimited. 


A Data Base Design 
For A Multimedia C2 Workstation 
In Support Of RESA 


by 


Michael F. Carroll 
Captain, United States Air Force 
B.A., Rutgers University, 1979 


Submitted in partial fulfillment of the 
requirements for the degree of 


MASTER OF SCIENCE IN SYSTEM TECHNOLOGY, 
(Command, Control and Communications) 


from the 


NAVAL POSTGRADUATE SCHOOL 
March 1987 


ABSTRACT 


This thesis supports the Naval Postgraduate School’s (NPS) program to develop 
a multimedia (text, voice, graphics) command and control (C2) workstation as a 
Decision Support System to aid players of the Research, Evaluation, and Systems 
Analysis (RESA) facility. RESA is a Naval wargame that focuses on the battle 
group/force level operations and command and control decision-making. NPS will 
interface this workstation with the wargame to provide players the capability to access 
and analyze game data in order to improve their decision-making ability. The objective 
of this thesis is to design a data base for the C2 workstation using data extracted from 
the game blackboard. The design will consist of a Semantic Data Model for the logical 
representation of the data and a relational data base design implemented on the 
ORACLE Data Base Management System (DBMS). This design provides a detailed 
specification of the data base structure and is intended to be used during 


implementation of the DBMS on the workstation. 
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I. INTRODUCTION 


A. THE MOVE TO DISTRIBUTED COMPUTING 

Over the past 15 to 20 years there has been a continuous and steady increase in 
the development of distributed computer systems. It is generally agreed this was made 
possible due to the recent advances in very large scale integration technology and the 
development of effective communications over local and wide area networks. It is now 
possible to purchase computer systems, which outperform the mainframes of the 1960's 
for just a fraction of their original cost. 

Although technology made distributed computing possible, it is the people and 
organizations that need the system and service it provides. As organizations expand, 
thev tend to become decentralized. Distributed computing is extremely well suited to 
companies exhibiting this structure. Distributed computing represents a more natural 
realization then a system built around a single large processor because it provides the 
organization functional separability and a nonuniform distribution of the database 
[Ref. 1: p. 24]. In addition, it potentially offers the user increased reliability, resource 
sharing, extensibility, and overall better performance. [Ref. 2: pp. 141-142] 

This move towards distributed computing may be interpreted that service to the 
user is becoming more important than hardware utilization. [Ref. 1: p. 38]. Most 
people are not familiar with computer hardware and software. Their only real interest 
is in using the computer as a tool in the performance of their job. How useful the tool 
is depends on the capabilities of the system and processors available. [Ref. 3: p. 38] 

Todavs high performance, 16-bit microprocessors come close to achieving the 
performance of minicomputers. In comparison to general purpose microprocessors they 
have vastly improved memory space, the ability to handle a greater variety of data, 
powerful arithmetic capabilities, and increased speed of operation. With such 
capability, operating systems are being designed to run on microprocessors to provide 
the user with graphic displays, digitized voice, windowing capability, electronic-mail, 
and many other features. Microprocessors that can support these features, or some 
combination, are sometimes referred to as multimedia workstations. It is this tvpe of 
workstation the Navy is trying to develop to enhance existing command and control 
(C2) systems. [Refs. 4,5: pp. 1, 11] 


B. PROBLEM STATEMENT 

Demands on current Navy C2 systems are constantly increasing due to the 
continuing advances in technology; weapons, surveillance and detection systems. This 
in turn increases the amount and variety of data C2 systems must handle. How easily 
this data is accessed, how quickly, and the way the data is presented, directly affects 
how well the system performs, or more explicitly, how well the C2 system assists the 
commander in making a decision. 

In order to better support the commander, the man-machine interface on the C2 
workstation must be more natural and efficient, readily adaptable to individual users, 
and able to support multimedia information. Yet, the Navv's current C2 workstations 
only operate with a single system and require specialized training. What they need is a 


workstation 


flexible enough to work with a wide variety of C2 svstems; and adaptable enough 
to meet the requirements of a diverse set of users. (with) .... Both voice and 
kevboard natural language interfaces (Ref. 4: p. 1]. 


The payoff from such a generic C2 multimedia workstation is a more robust approach 
to distributed command and control. [Ref. 4: p. 1] 

The Naval Postgraduate School (NPS) is currently investigating the use of a 
generic C2 workstation as a Decision Support System to aid players of the Research, 
Evaluation, and Systems Analvsis (RESA) facility [Ref. 6: p. 1]. This is part of the 
Office of Naval Technology program NO2CRC32S10 which is a research program in 
distributed command and control. RESA is a computer-based, large-scale wargame 
simulation of the Naval warfare environment [Ref. 7: p. 1.6]. It focuses on battle 
group force level operations and command and control decision making. The Naval 
Ocean Systems Center (NOSC) has chosen the SUN microsystems’ version of the 
UNIX operating system along with the Relational Data Base Management System 
ORACLE to function as the C2 workstation.! NPS intends to interface this 
workstation with the RESA wargame to provide players the capability of real-time data 


extraction, via a natural language, in order to enhance their decision making abilities. 


l Additional information on the Sun microsystem, UNIX, and ORACLE is 
provided in Appendix A and B. 


This arrangement allows the RESA players, umpires, or analysts, to have access 
to organized data at nearly the same time it is generated in the RESA system. Real 
time access to data involving the current tactical situation permits players to analyze 
this data to improve the quality of their next decision or action in the wargame. It 
should help players favorably control the outcome of events by reducing the number of 
bad decisions. Data made available by this svstem allows umpires to identify trends, 
preclude misapplication of gaming rules, and in the process to better control the game. 
In the analysis phase, this workstation provides data which has been obtained in 
several wargame scenarios to research problems on individual components or weapon 
systems, and to study command and control relationships in Naval and Joint Tactical 
Operations. 

Installing this workstation is only the first step in NPS’s program. There are 
plans to interface existing HP 9020 workstations onto the Sun/RESA local area 
network to allow additional users to access the wargame data base and to function as 
independent command nodes. The long term goal at NPS is to access the Defense Data 
Network (DDN) and provide connectivity to the RESA facility located at NOSC, San 
Diego, Ca. This connectivity will allow the study of a class of C2 problems concerning 
coordination at the headquarters level. In the Navy context, this allows researchers to 
study problems associated with ship-to-ship distributed command and control and to 


apply large computing systems to these problems in real time. 


C. STRUCTURE OF THE C2 WORKSTATION 

Ihe overall structure of the workstation is shown in Figure 1.1 and depicts the 
basic modules required to interface the workstation with the wargame, access the data 
base, and provide the desired natural language interfaces. Module A is the only part of 
the system that presently exists except for the voice interface. This is being built at 
Standford Research Institute, Incorporated. The menu selection module is a proposed 
interim solution until a sufficient natural language module can be designed for the 
system. This would allow the user to interact with the computer by using the same 
language structure as when talking to another person. However, true natural language 
systems are still in their infancy. They require high levels of vocabulary and syntax 
flexibility, while menu-based systems require less computer memory and appear to be 


well suited for command and control queries (Ref. SJ. The Naval Ocean Systems 
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Figure 1.1 Concept of a C2 workstation as a DSS. 


Senter | NOo@micentiiied the need for the ORACLE/RESA interface module.” They 
have alreadv written the program to extract the data from the RESA wargame, but it 
will be necessary to reformat the data to make it compatible with ORACLE. After 
reviewing this structure, the next logical step in implementing this workstation is to 
develop the ORACLE data base module. The structure and content of the data base 


must be developed before the rest of the modules can be completed. 


D. PURPOSE 

The purpose of this thesis is to design a data base for the SUN Workstation in 
support of RESA. The design will include a Semantic Data Model (SDM), which 1s a 
logical description of the data, and a Relational Data Base Design, appropriate for 
implementing on the ORACLE DBMS. In addition, several sample queries, using 
ORACLE's SQL query language will be constructed to illustrate the tvpes of 


information the user will be able to extract from the data base. 


NOS c This information was provided via a phone conversation between the author and 
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E. SCOPE OF WORK 

The thesis is structured as follows. Chapter II describes the components of a 
Decision Support System and a Data Base Management System and how they can be 
used to support C2 systems. Data base processing is the main focus of Chapter III 
and IV. Chapter III describes the terminology and procedures used to create a 
Semantic Data Model (SDM). The purpose, characteristics and benefits of the SDM 
are discussed in detail. The SDM is created for the C2 workstation using data received 
from the Naval Ocean Systems Center in San Diego, CA. A portion of this schema is 
described to illustrate the concepts of SDM. Chapter IV identifies characteristics of a 
Relational Data Base Design, its format and then describes the relational design 
developed for the C2 workstation. Sample queries on the data base are provided at the 
end of Chapter IV in order to tie both the SDM and relational data base design 
together. This is followed by recommendations and conclusions for continued work in 
this area. Appendices contain information on the Sun Workstation, ORACLE DBMS, 
the data provided by NOSC, and the complete Semantic Data Model for the C2 
workstation. This work does not include implementing the relational data base design 
using ORACLE. 
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11. BACKGROUND 


Chapter II provides background information on the structure of Decision 
Support Systems and Data Base Management Systems. It defines both of these systems 
and describes their individual components, characteristics, and capabilities. In addition, 
Decision Support Systems are described in relation to their potential to improve the 


current comand and control decision-making process. 


A. DECISION SUPPORT SYSTEM (DSS) 
l. What is a DSS? 

As previously mentioned, the Navy is developing a C2 workstation as a 
Decision Support System to aid players of the RESA war game. Such a system 
provides the potential for players to use information by filtering, analyzing data, and 
comparing alternatives [Ref. 9: p. 9]. It will help them make decisions concerning their 
next move in the game by considering “what if” situations. This is exactly what a DSS 
is supposed to do. 

a. Definition 

A DSS is a computer-based, online, interactive system that helps 
commanders make key decisions. thereby improving the effectiveness of their problem 
solving process. It incorporates the experience and instinct of the decision-maker to 
analyze hypothetical questions before implementing an irrevocable decision. 
[Refs. 10,11: pp. 24, 4] 

b. Components of a DSS 

DSSs are characterized as localized, autonomous systems containing 
analytical modules having free access to information. They generally consist of a data 
base management system (DBMS), report generator, a data base query language, 
graphics package, and special-purpose software [Ref. 10: p. 24]. Conceptually, this 
breaks down into four basic modules E [Kek pp 0:15] 

l. Control - this is the user-interface or front-end of the system. It is usually menu- 
driven with kevboard inputs and interfaces with the other three modules. It 
provides prompts and messages to guide the user in formatting the problem and 
generating a response. 

2. Data storage - contains all data required by the DSS. 

Data manipulation - this is responsible for retrieving data from the data storage 


a 
module and producing reports or SE E the data. It 1s supported by a 
nonprocedural query language normally provided by the DBMS. 


G2 
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4. Model-building -. utilizes E modeling principles, statistical analysis, 
forecasting algorithms, decision analysis methods, and simulation principles for 
modeling and simulation purposes. 


These four modules must also display certain characteristics to be considered a true 


DSS. 


MODEL-BUILDING DATA STORAGE 
MODULE MODULE 


USER INPUT 





Figure 2.1 Component modules of a DSS. 


c. Characteristics 
Generally speaking, a particular system is only considered a DSS if it 
provides interactive support for the thought processes of one or more decision-makers. 
Systems used in this way must exhibit certain characteristics. Among these are: 
(Refs. 12,13; pols, 77270) 


l. Fiexibilty - a, DSS must, accommodate and support decisions, under highly 
varying conditions, on an “ad-hoc” basis. 


2. User-friendliness - the system is tvpically designed for a user unfamiliar with 
computers. If necessary, it can guide users in operating the system. 


3. Natural language capability - DSSs must communicate in terms familiar to the 
user. 


4. Timeliness - speed of response is necessary to maintain continuity of the user's 
own thought processes. 


5. Enhanced 0 ک0‎ - a DSS must exhibit a structure which is 
understood by the user and reflects his own way of thinking. 
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6. DSS must be TEN the system must evolve, grow and be easily and 
quickly modified to meet changing Circumstances. 


These characteristics are the ideals or norms of the DSS concept. They are necessary 
for handling a variety of problems a decision-maker may encounter. 
2. Technical Capabilities of DSSs 
a. Functions 

The primary function of a DSS is to assist decision makers in solving “what 
if’ type questions. These consist of unstructured or semi-structured problems related to 
strategic planning, management or operational control [Ref. 14: p. 8]. Unstructured 
problems are those activities in which the solution objectives are ambiguous, 
numerous, and the process required to achieve a solution cannot be specified in 
advance. It is an activity involving a decision process which is partly routine and 
partly judgmental. Whereas the routine part can be automated in a computer program, 
the judgmental aspect is the responsibility of the decision-maker. [Refs. 11,12: pp. 7, 
15] 

Goal seeking is another major contribution offered by a DSS. By 
assembling appropriate analytical and simulation models on the system, the decision- 
maker can pick a desired goal. The DSS then seeks the optimal decision path or set of 
solutions to arrive at the specified outcome. [Ref. 10: p. 25] 

DSSs also perform two other functions for the decision-maker. First, it 
allows users to manage verv large data bases, where the manager may have difficulty in 


accessing and making conceptual use of all the information. 


Determining where to look for a particular piece of information is a nontrivial 
issue. Actually retrieving it can be a substantial task which complicates and slows 
the process of command decision [Ref. 15: p. 29]. 


DSSs reduces this problem by offering real-time data extraction and data manipulation 
or computation in order to arrive at a solution or suggested alternative. The second 
function a DSS provides is the ability to handle time-sensitive issues. These issues are 
especially common on the battlefield. As new technology is introduced to the 
battlefield, the critical response times required for decisions grow shorter at all levels of 
the command hierarchy. The human elements of the system are not able to respond 
fast enough and require some form of automation to assist in their analysis of data and 


other environmental factors. [Ref. 15: p. 28] DSSs provide this capability and offer the 


commander the opportunity to review the problem and choose an acceptable solution 
in time to meet the immediate threat. DSSs provide this automation for the decision- 
maker, thereby reducing the time required to make a decision. [Ref. 11: p. 7] 
b. Levels of Support 

There are four levels of support available from a DSS [Ref. 11: p. 9]. These 
areas were briefly discussed throughout the beginning of this chapter and are 
summarized here as part of the capabilities provided by the system. They are: 

|l. Access to facts or information retrieval. 


2. Addition of filters to selectively ask for information and give conceptual 
meaning to data. 


3. Ability to perform simple computations, comparisons, and projections. 


4. Development of useful. models designed to provide the decision-maker with 
answers they can and will act on. 


These functions and capabilities are the reasons why DSS are being developed to assist 
command and control (C2) systems. 
3. Command and Control DSSs 

To understand why DSSs are being used in C2 systems it is necessary to 
understand the C2 decision making process. According to Joel S. Lawson, this process 
consists of five phases; sense, process, compare, decide, and act. The process, compare, 
and decide phase is where a DSS will be able to help improve the present capabilities 
of C2 systems. The process function extracts meaning from the signals it receives from 
the sensors and then generates event and status reports in its assessment of the 
situation. The compare function evaluates the options by comparing the local 
environment as seen from the status reports to some other desired state. Based upon 
this comparison, the decide function then determines what should be done in order to 
achieve the desired state or goal. [Ref. 16: pp. 24-25] 

A DSS is very similiar to the C2 decision making process. The system allows 
quick access to facts and information and filters and displays the information in a 
representative form (graphics and charts) that give conceptual meaning to the data. 
This is like Lawson's process function. The systems ability to assist the decision maker 
in solving “what if” type questions is equavilent to Lawson’s compare function, while 
“goal seeking” is more comparable to Lawson’s decide function. The advantage 
command and control DSS offers the commander is the ability to handle a wide range 
of problems under varying time constraints. It is this very need for accurate data, and 


fast and timely decisions in a very violatile and uncertain environment that provides 
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the justification for DSSs. [Ref. 14: p. 11] However, in order for a DSS to provide the 
commander non-routine information through “ad-hoc” queries, the system must have a 
suitable data base management system [Ref. 11: p. 6]. 


B. DATA BASE MANAGEMENT SYSTEMS 
1. Basic Terminology 

In order to discuss a Data Base Management System (DBMS) it is necessary 
to define some basic terms and concepts: A Data item, which is also called a field or 
attribute, is a group of non-random symbols that represent quantities. actions, things, 
facts, concepts or instructions. A File is a collection of related records and a Data Base 
is a collection of files logically related in such a way as to improve access to data. A 
Data Base Management System is a software system capable of supporting and 
managing an integrated data base. Finally, a Conceptual Model or data model is a 
logical representation of the information (data that has been processed and presented) 

con aneda he data Dase. [Refs. 17,18: pp. 5, 3] 

2. What is a Data Base Management System? 
a. Definition 

A data base management system is a complex, usually large program that 
acts as a data librarian which stores and retrieves data from a data base [Ref. 19: p. 3]. 
‘Its most attractive feature is its collection of integrated, shareable, and nonredundant 
data. An integrated data base brings together a variety of data which can be accessed 
bv more than one user. This ability to share data keeps the amount of redundant 
storage to a minimum. [Ref. 17: p. 5] Simply put, a DBMS is software consisting of a 
set of tools or features to manipulate and support the data base. The fundamental 

features provided by a DBMS are: [Ref. 18: p. 4] 


l. Centralized control of the data, which implies reduction of data redundancy, 
shared data, protection of the data base integrity, and enforcement of standards. 


2. Data jan ne nee the ability to modify the data base structure without 
having to modify the programs which use the data. 


3. Provision for complex file structures and access paths. such that relevant 
relationships between data units can be expressed in a natural form. 


4. Generalized facilities for storage, modification, reorganization, analysis and 
retrieval of data. This is done with programming languages, a user query 
language or both. 

5. Security to prevent unauthorized access to stored data. 


6. Mechanisms to enable easy recovery or restoration of the data base. 
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3. Organization 
The data base organization can be visualized as three separate realms, as seen 
in Figure 2.2 [Ref. 17: pp.16-17]. The conceptual level is independent of computer 
hardware. It is a picture of the data base as visualized by the user of the DBMS. There 
are currently three main types of conceptual data base models available. They are: 
[Ref. 19: pp. 117, 120, 196] 

l. Hierarchic - the structure is in the form of a tree with a one-to-many 
relationship among records. An individual record (node) may only have one 
owner (parent). It is a subset of network. 

2. Network - is a collection of records exhibiting either a one-to-many or many-to- 
manv relationship among records. An individual record may have more than 
one parent. 

Relational - represented in the format of a table called a relation. Rows of the 


table are file records or tuples and fields of the relations are shown in the 
columns called attributes. 


LA) 


These models describe the structure and processing of the data base. 

The logical level is the equivalent model of the user's view of the data but it 1s 
organized in accordance with a particular data base svstem model, ie. hierarchy, 
inverted hierarchy, network or relational DBMS. The final level is the physical data 
base structure realm which represents all data definition directories, access paths and 
methods, and the actual data itself. 

4. Composition 

The actual composition of a DBMS depends on the vendor. Larger computers 
can support more elaborate DBMS providing a greater variety of tools. Smaller 
svstems, like microcomputers, restrict the size of DBMS and therefore, reduce the 
number of tools available. However, there are two major features common to all 
DBMS. They are the Data Definition Language (DDL) and the Data Manipulation 
Language (DML). [Ref. 19: p. 191] 

DDL is a vocabulary for describing the “schema” and “subschema.” The 
schema 1s the description of the complete logical data base, and the subschema is the 
description of a subset of that data base used by an individual computer program. The 
DDL includes terms for defining records, fields, keys, and relationships. It should also 
provide the means to express a variety of user views and data base constraints. 
[Rer 18 pasi 

The DML is a vocabulary for describing the processes (retrieving or changing) 
that can be performed on the data in the data base. There are two tvpes of DML: 


procedural and nonprocedural. Procedural DMLs use high level programming 
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Figure 2.2 Realms of a data base management system. 


languages (such as COBOL and FORTRAN) to access the data base. They describe 
explicitly the actions to be performed on the data base. Nonprocedural DMLs simply 
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state what is wanted but not how to obtain it. Nonprocedural-DMLs are directed 
towards noncomputer specialists. 
5. DBMS Utilization 

Data base management systems are valuable wherever there is a requirement 
to manage an integrated data base. Continuing advances in computers have resulted in 
similiar advances in DBMS. They now operate on microcomputers and workstations as 
well as the large mainframe computer systems. DBMS are used in business 
applications, the military (such as wargaming and decision support systems), and in 
research facilities. All three of these areas share the identical problem of trying to 
manage vast amounts of data in a timely and effective manner. NPS has chosen 
ORACLE as the relational DBMS for their DSS C2 workstation. Representative data 
created during play of wargaming scenarios and provided by NOSC, will be utilized as 
a surrogate for actual operational data. This data provides a wide spectrum of process 


records for the analyst and system designer alike. 


C. SUMMARY 

Chapter II defined DSSs as a computer-based, interactive system that 
incorporated the experience and instinct of the decision-maker to analyze hypothetical, 
“what if” type questions. These systems require flexibility, user-friendliness, a natural 
language capability, timeliness, and evolutionary characteristics. The advantage that a 
DSS offers to the commander is the ability to improve the process, compare, and 
decide phases of the command and control decision-making process. In order for a 
DSS to support “ad hoc” queries from the user, a suitable data base management 
system is required. A DBMS is defined as a complex, usually large program which 
stores and retrieves data from a data base. Organizationally, the DBMS consists of 
three levels; the conceptual (or user’s perception of the data base), the logical level 
(which defines the user’s perceptions in terms of a particular DBMS), and the physical 
level (which contains the actual data itself). Specific applications for DBMSs include 
wargaming and decision support systems. However, a data base design is required 
before any system can be implemented and Chapter III describes the methodolgy used 


to design such a logical data base design. 
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Ill. A LOGICAL DATA BASE DESIGN USING SDM 


This chapter describes the procedures and format used to develop the logical data 
base for the C2 workstation using a Semantic Data Model. The first section analyzes 
the data received from the Naval Ocean Systems Center (NOSC). Then, the basic 
structure and models used in the logical data base design are described with particular 
attention given to the Semantic Data Model. Specifically, the characteristics, benefits, 
purpose, and format of the SDM are discussed. Finally, a narrative description of the 
SDM schema developed for the C2 workstation is provided with a detailed explanation 


of one of its entity classes. 


A. OVERVIEW 

What actually constitutes a data base design varies from author to author and 
certain areas tend to overlap. We will use the method suggested bv David Korenke in 
his book Data Base Processing [Ref. 19]. According to Kroenke, data base design is a 
two-phased process consisting of a logical data base and a physical design. First, the 
user's requirements are examined and a conceptual data base structure is created to 
model their organization. This is called the logical data base design. In. our case the 
logical design is represented using the SDM. Once this design is complete, it is 
formatted in terms of a particular DBMS. In our case this is a relational DBMS since 
ORACLE is the chosen DBMS for the workstation. This second step is called the 
physical data base design. 

Data base design is an intuitive and artistic process. There is no algorithm for it. 
[Ref. 19: p. 177] It is an interactive process with the goal to get closer to an acceptable 
design. The data base is a bridge between people and hardware and the designer must 
consider both these characteristics. The logical design specifies the needs of the people. 
The physical design maps the logical design into constraints of a particular program 
and hardware products. “The goal when developing a data base design is to make only 


uninteresting questions unanswerable.” [Ref. 19: p. 206] 


B. ANALYSIS OF DATA 
The data used in this design was supplied by NOSC in San Diego, Ca. NOSC 


wrote the computer program to extract this data from the RESA wargame's 


blackboard and the data are updated once every minute of game play. The data are run 
through a TAPE_PIPE.EXEC computer program, also supplied by NOSC, which 
separates the data into six associated files corresponding to RESA tables. The common 
denominators between all files are the game time and associated slot number. These are 
control numbers used bv the computer program as it extracts the data from the 
blackboard. They also serve a secondary purpose, which is to relate the separated data 
fles to one another. A sample listing of data, their associated fields, and an 
explanation of their interrelationships is provided in Appendix C. It is this data that 


will be used to develop the logical data base and relational data base design. 


C. LOGICAL DATA BASE DESIGN 

The logical data base design specifies the logical format of the data base. It is 
sometimes called the schema or logical schema. It identifies the records maintained, 
their contents and the relationship among the records. The contents of each record 
contains field names and their required format. As requirements are evaluated 
constraints on data items are identified. There are three types [Ref. 19: p. 179]. A field 
constraint limits the value a given data item may have. [nirarecord constraints limits 
values between fields within a record and interrecord constraints limit values between 
fields in different records. The level of record detail depends on the designer. There are 
few records if the model is highly aggregated and generalized or many records if very 
detailed. 

In developing the schema the assigning of data items is relatively straightforward 
for two-thirds to three-fourths of the record types, but problems do arise. Some of 
these files may need to be combined or separated, and if this is done, does it make the 
design more effective? The designer must also allow for growth and anticipate future 
requirements of the user. A final problem encountered concerns “implied” data. This is 
an item that is needed to meet a requirement but is not visible to the user. [Ref. 19: p. 
182] 

The second step in developing the schema is determining the relationships among 
the records [Ref. I9: p. 182]. ۲1٠٠16516167١١١١) >٠ 
relationships. This is done intuitively, but in designing relationships, the designer must 
distinguish between theoretical and useful ones. A theoretical relationship can exist 
logically but, in practice, may never be needed. “In general, if there is any question 
regarding whether a relationship is useful or not, then the relationship should be 
included in the logical schema.” [Ref. 19: p. 186] 
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1. Logical Design Structures (Primitives) 

Before it is possible to design files and relationships, it is necessary to 
understand the foundations of data modeling. The data base design is only a 
representation of reality. It is a model of some activity, a conceptual presentation of 
real world structures or primitives. [Ref. 19: p. 205] 

Primitives in the real world consist of objects, object classes, properties, 
property value sets, facts, and associations. An object is defined as some phenomena 
that can be represented by nouns, such as a ship. Object classes (ships) are merely 
groups of objects formed by generalizations. Properties are the characteristics of these 
objects and the collection of all values a property can have is called the property value 
set. The intersection of a given object with a given property value set is called a fact. 
This concept is illustrated in Figure 3.1. Finally, an association is the connection of 
objects of the same or different classes and thev may also have properties. [Ref. 19: p. 
207] 


HEIGHT PROPERTY 
VALUE SET 


FACT 


RAY HARRIS 67 INCHES 27 YEARS OLD BASKETBALL SKILL A 


OBJECT 











77 INCHES 
74 INCHES 
59 INCHES 


Figure 3.1 Example of primitive fact. 


Only a representation of these real world primitives is used in designing a data 
base. A 74 inch person can be inserted into a car or ship, but not into a data base. 
Therefore, data base experts have defined a conceptual primitive for each of the real 
world primitives. They are entity, entity classes, attributes, domain (which is the 


collection of all values an attribute can have), a value (which is the intersection of a 
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given entity with a given domain), and a relationship. The equivalences between real 


world and conceptual primitives is depicted in Figure 3.2 [Ref. 19: p. 209]. These 


Real World Primitive Conceptual Primitive 


Object Entit 
Object Class some Class 


Property Attribute 
0 Value Set Domain 

Fact `. alue i 
Association Relationship 





Figure 3.2 Equivalencies between real world and conceptual primitives. 


conceptual primitives will be used in the development of the logical data base design. 
2. Data Base Models 

All data bases are a model of some system in the real world. The actual data 
represents events, frozen in time, that occurred in the application environment. Any 
change to the data base should only occur if a similiar change occurred in the 
environment. This means the structure of the data base should “mirror” the structure of 
the system it models. It is easier for the data base designer to build and modify the 
data base when it is based on naturally occurring structures in the environment. This 
same rationale can be applied to the data base user. If data bases are described in 
terms and concepts familiar to the user, then it should become easier to understand 
and employ the data base. [Ref. 20: pp. 351-352] 

A data base model is defined as a logical schema "specified in terms of a 
particular data base description and structuring formalism and associated operations.” 
[Ref. 20: p. 352] These models are important tools for designing both logical and 
physical data bases. There are many useful models available, such as the Entity- 
Relationship model, the Relational Data model, and the CODASYL DBTG model. 
They range from being human-oriented on one side to machine-oriented on the other. 
All these models have one thing in common; they describe the structure and processing 
of a data base. 

The Semantic Data Model (SDM), as developed by Hammer and McLeod and 
first published in 1981 [Ref. 20], will be used for the development of the logical data 


base design. This model is human oriented, and because of its semantic nature, SDM 
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is recommended for logical data base design. Hammer and McLeod do not believe the 
data structures provided by contemporary data base models, such as those listed above, 
adequately support the design, evolution, and use of complex data bases. They are 
significantly limited in their capability to express the meaning of the data base to its 


corresponding application environment. 


The semantics of a data base defined in terms of these mechanisms are not 

readily apparent from the schema; instead the semantics must be separately 

specified by the data base designer and consciously applied by the user 
EDO. 552] 


We believe that SDM provides better facilities (than models like the Relational Data 
Model or the Entity-Relationship Model) for expressing meaning about data, avoiding 
confusion, and documenting design decisions and constraints [Ref. 19: p. 194]. 
3. Goal and Benefits of SDM 

The goal of SDM is to enable the data base designer to directly incorporate 
more meaning and relationship about the data into the logical schema. It serves as a 
modeling mechanism to express the natural structure of the environment in the 
structure of the data base design. SDM provides several benefits to the user. First, it is 
a formal technique to describe meaning about the data base. It provides precise 
documentation of the data and it is a communication medium which allows the user to 
determine what information is contained in the data base. Second, SDM allows the 
construction of user interfaces to the data base which improves the process of 
identifying and retrieving relevant information. These can be front-ends to existing data 
base management systems (DBMS) or query languages for new DBMSs. An additional 
benefit of SDM is it supports effective and structured design of data bases. 
۲۶۰٠٦ ٥٣٢٣٣. 352-555] 

4. Design Criteria of SDM 

The Semantic Data Model was developed by Hammer and McLeod to meet a 
number of criteria not met by the contemporary data base models. They felt the data 
base should be designed to provide specific meaning to a large portion of the data base. 
In addition, it should support a view related to the meaning of the data base and have 
a structure which supports different ways of viewing the same information. This 
requires a data base model be 


l. Flexible - allow for multiple and coequal views of data 


2. Logically redundant - values of components can be derived from other 
components in the data base 


3. Integrated - this describes the relationships of a data item viewed in different 
ways 


The last essential criteria for SDM is it must be able to describe relevant entities 
(which represent objects in the real world environment), groups of these entities, their 
relationships, and the interrelationships among the groups. [Ref. 20: pp. 353-354] 
5. Structured Format of SDM 
We will now discuss the SDM format which is displayed in Figure 3.3 


[Ref. 19: p. 213]. A data base is viewed as a collection of entities that correspond to 


ENTITY_CLASS_NAME 


description: 
interclass connection: 


member attributes: 
Attribute name 
value class: 


mandatory 
multivalued, no overlap in values 
exhausts value class 
not changeable 
inverse: Attribute name . 
match: Attribute name of ENTITY CLASS 
. . On Attribute name2 
.. derivation: 
class attributes: 


Attribute name 


description: 


value class: 


۱ ۱ derivation: 
identifiers: ۱ 
Attribute namel + (Attribute_name2 + (...) ) 





Figure 3.3 SDM format of entity class description. 


the actual objects in the application environment. These entities are organized into 
classes that are meaningful collections of entities. The class name identifies the class of 
entities and must be unique with respect to all other class names in the schema. The 


description defines the purpose and content of the class. It describes the specific nature 


of the entities and indicates their significance and role in the application environment. 
[Ref. 20: pp. 355-356] 

The class is composed of a collection of members or entities. These entities 
correspond to various kinds of objects in the application environment such as concrete 
objects, events, categorizations or syntactic identifiers (STRINGS). STRINGS are any 
character string which the designer wants. There are two types of attributes which 
describe the members of the class or the class as a whole: a member attribute or class 
attribute. The member attribute describes an aspect of each member of a class by 
logically connecting the member to one or more related entities in the same or another 
class. The class attribute describes the property of a class as a whole and not any 
particular member. [Ref. 20: pp. 356-357] 

A class can either be a base class or a nonbase class. A base class is defined 
independently of all other classes whereas a nonbase class does not have an 
independent existence, but is defined in terms of one or more other classes. These 
nonbase classes are related bv means of an interclass connection which describes how 
the class is constructed. There are two types; a subclass connection is a class that 
contains some but not necessarily all of the members of another class and the grouping 
connection has members that may themselves be viewed as classes. [Ref. 20: pp. 
357-358] 

Data base entities and classes have attributes that describe their characteristics 
and relate them to other entities. These member attributes have value classes which 
may be an entity in the data base or a collection of such entities. The value class 
contains the permissible values of that attribute and may be derived from other values 
in the data base. There may or may not be constraints and relationships on member 
attributes. If any, they are defined as follows. 

l. multivalued- this is like a repeating field, there is more than one. For example, a 
ship may be described as a particular type such as a destroyer. This would be 
considered singlevalued since it can not_be defined as any other type. However 
this same ship may have many kinds of weapon systems: Therefore weapons, if 
listed as a member attribute would be multivalued. 

2. Mandatory - the null value is never accepted. Tvpe from the previous example 
can be thought of as a mandatory constraint. Every ship must be described by 
type, cruiser or destroyer, whenever it is listed in the data base. 

3. Not changeable - the value of an attribute must remain the same. This means 
the value, once set, cannot be changed except to correct an error. If the tvpe of 
ship listed was wrong, then the value can be changed. 

4. Exhaustive - every member of the value class must be used. For example, if 


engines were listed as a member attribute of an entitv class called SHIPS, then 
every engine entity listed must be an engine on some Ship. 


Non overlapping - a member of the value class can be used at most once or not 
at all. If the engine of the entity class SHIPS were specified as non-overlapping, 
then this means that any enginé listed can be in only one ship. 


Lë 


6. Inverse - this causes two entities to be contained in each other. For example, if 
two entity classes were defined as PITCHERS and RECIPES then these would 
be inverses if a member attribute from each entity class had a, value class listed 
as PITCHERS and RECIPES. Let us assume that kinda E used is à 
member attribute of PITCHER and its value. class is RECIPES, and 
pitcher recipe used in has a value class of PITCHERS. These then are 
considéred to be inVerse of each other. 


7. Matching - a member of one entity class is matched with a member of another 
entitv class. This means the, value of an attribute in one of the members is 
movéd to the other member in another entity class. As an example, let SHIPS 
and ASSIGNMENTS be defined as entity classes with member attributes of 
Captain and so) respectively. If Captain is matched to Officer of 
ASSIGNMENT then the value” of Caprain is determined by the value of 
Officer from ASSIGNMENTS for a particular ship. 

8. Derivations - these are statements clarifving how to derive an attribute. They 
can also be used to specifv relationships among members 1n the, same entity 
class. An example is a class attribute of total number of ships. lhis is then 
derived by summing the total number of ships listed in the entity class SHIPS. 

Finally, the identifiers are unique Keys which identify individual records. This is the 
format used to develop the SDM schema described in the next section and Appendix 


D. [Refs. 19,20: pp. 213-224, 363-365] 


D. DESCRIPTION OF THE SDM SCHEMA FOR THE C2 WORKSTATION 
The identification of the data extracted from the RESA wargame has already 
been completed by the Naval Ocean Systems Center (NOSC). We transcribe the data 
into an SDM schema and tailor it to meet the needs of NPS, occasionally deleting 
certain items which seemed to have no real value to the user.? The information in this 
process was obtained from the blackboard in the RESA data base, while constraints on 
the data were identified by evaluating the sample output data supplied by NOSC. The 
data are broken down into six basic areas or entity classes based on the tvpe of 
information available to the user. These classes are: 
l. Active units- this describes all units, whether hostile or friendly, which are 
participating in the wargame scenario. Units can be ships, shore bases, aircraft, 
submarines or cruise missiles. 


2. Remote detections- contains the apparent latitude and longitudinal position of all 
detected targets such as aircraft or cruise missiles. 


3. True position- this entity class provides ground-true latitude and longitudinal 
position for each active unit in the game. 


4. uud damages- identifies what unit was damaged, the time it occurred, and 
which general areas sustained damage. For example, it will indicate if a ship is 
sinking or its maximum speed possible aíter being damaged. 


Those items deleted were discussed with personnel at NOSC to confirm their 
intended use in the data base. 


5. Dynamic information - contains oa information for each active unit. It 
includes the peut of damage suffered by a unit and the amount of equipment 
remaining after being damaged. In addition, it provides an accounting for 
weapon expenditures during combat operations by keeping track of the number 
of missiles remaining and other similiar items. 

6. Engagement data- provides information on aircraft and ships engaged in combat 
Operations. It includes calculated, probabilities on aircraft. air-to-air missile 
strikes and on an launched missiles for interception of incoming cruise 
missiles. It defines the current position of both the, attacking unit and target 
and the status of the target after the engagement 1.e., whether it was hit or 
destroved. 

E. DESCRIPTION OF SDM ENTITY CLASS ACTIVE UNITS 

It should be noted that certain formats in the domains of the value classes listed 
in this schema were changed from those originally specified in the RESA blackboard. 
This was done to accommodate the players of the wargame, since this workstation will 
also be used as a DSS to interact with the game on a real time basis." For example, it 
will be much easier to read the name of an item than trying to interpret what a 
particular number is supposed to mean, especially when the range of possible total 
values exceeds ten. Since this workstation is supposed to assist the decision-maker we 
felt it was necessary to make these changes. The entity class ACTIVE UNITS is 
shown in Figure 3.4 to illustrate the SDM concepts discussed in this chapter. The 
complete SDM schema ts listed in Appendix D. 

ACTIVE UNITS describes those units which are participating in the war 
scenario. The member attributes for each specific unit are Name, Stratus, View, Type, 
Assigned target of unit, Bomb hits, and Missile hits. The unique identifier for this 
entity class is Name since no two names within ACTIVE UNITS are the same. The 
member attribute ;Vame has a value class of UNIT NAMES. This is a subclass of 
STRINGS having a maximum length of eight characters which identifies the name of 
each unit. It is considered mandatory, along with member attributes Status, View, and 
Type because these are the minimal members that must be contained in the entity class. 
If there is no Name then no other information should be provided. If there is a Name 
then the minimum information needed for each unit are Starus, which describes the 
present condition of the unit, View, which identifies the unit as hostile, friendly or 
neutral, and Type, which identifies whether the unit is a ship, submarine or aircraft. 
The value class of Status is UNIT STATUS which is a subclass of STRINGS whose 
format is an integer from 0 to 10. For example, 0 indicates if the unit is being deleted, 2 


if the unit is on station and 3 if the unit is proceeding. View has a value class equal to 


^NOSC only uses their workstation for post game analysis. 
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ACTIVE_UNITS 


description: Contains names, pointers, and other “quick reference’ data 
for all active ships, shore bases, aircraft flights, and cruise missiles. 


member attributes: 
Name 


value class: UNIT NAMES 
mandatory 


Status 


description: contains present condition of unit, for example. 
sinking or on station. 


value class: UNIT_STATUS 
mandatory 


View 
description: identifies character of unit, for example, hostile. 


value class: DISPOSITION 
mandatory 


Type 


description: identifies kind of unit, for example, submarine 
Or cruise missile. 


value class: TYPE UNIT 
mandatory 


Assigned target of unit 
description: it indicates the target unit 1s attacking. 
value class: UNIT, NAMES 

Bomb hits 


description: contains number of bomb hits a unit received 
during a current game cycle. 


value class: NUMBER_EPU 
multivalued 7 


Missile_hits 


description: contains number of missile hits a unit received 
during a current game cycle. 


value class: NUMBER EPU 
multivalued 7 


identifiers: 


Name 


Figure 3.4 SDMentuüty class ACTIVE UNITS. 
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DISPOSITION. This is a subclass of STRINGS whose format is an integer from 0 to 
10. In this case a 1 indicates the unit is neutral, a 2 if friendly, and 3 if hostile. The 
value class Type is TYPE UNIT. This is another subclass of STRINGS whose format 
is an integer from 0 to 10. Examples of these values are: 1 identifies the unit as an 
aircraft, 5 identifies a cruise missile and 4 indicates an aircraft carrier. 
Assigned target of unit identifies which target the unit is currently attacking such as an 
aircraft or cruise missile. There is no mandatory value for this member attribute since 
it can assume a null value. There are times when a ship may not be engaged in combat 
operations. Its value class is UNIT NAMES. Bomb hits and Missile hits are member 
attributes that are considered multivalued attributes. An individual unit can receive 
more then one hit bv a bomb or be hit by more then one missile. They share the same 
value class NUMBER_EPU. This identifies the number of explosive power units 
(EPUs) received by a unit. It is a subclass of STRINGS whose format is an integer 
from 0 to 200. The rest of the entity classes defined in the SDM for the C2 workstation 
are contained in Appendix D. 


F. SUMMARY 

Chapter III describes the methodology used in the logical data base design. This 
design contains the conceptual data base structure which models the users 
requirements for the organization. The Semantic Data Model was used to develop the 
logical schema for the C2 workstation based on data received from the Naval Ocean 
Systems Center. This model was chosen over existing data base models like the 
Relational Data Model or Entity Relationship Model because it provides better 
facilities to express meaning about the data, avoid confusion and document design 
decisions and constraints. SDM 1s a mechanism to describe the meaning of the data 
base. It provides a variety of semantic-based user interfaces to the data base, and it is 
the foundation of effective and structured design for data bases. The basic format of 
SDM consists of an entity class (a group of entities corresponding to actual objects in 
the environment), member attributes (characteristics of the entity class), and a value 
class (which are the permissible values an attribute may have). 

A narrative description of the SDM developed for the C2 workstation was 
provided in the last section. [t was divided into six basic entity classes. The first class 
described individual characteristics of all active units in the wargame and was described 


in detail in this chapter to illustrate the concept of SDM. The next two identified 
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apparent and true locations of detected targets and active units respectively. The fourth 
entity class identified areas of damage that a unit sustained while the next one 
contained specific information on the amount of damage received and expenditure of 
resources of a particular unit. The last class described data on units engaged in actual 
combat. This schema forms the basis for developing the relational data base design 
which is described in Chapter IV. 
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IV. A RELATIONAL DATA BASE DESIGN USING ORACLE 


This chapter 1s divided into two major sections. The first describes the criteria, 
components, and format used in developing a relational data base design. The second 
section transposes the SDM in Appendix D into a relational data base design for the 
C2 workstation. It begins by describing the current system used by NOSC to extract 
data from the RESA wargame and to transfer it to their data base management system 
(DBMS) on their own workstation. This system is used to identify similiar areas of 
work which will be required before NPS can implement their own DBMS. In addition, 
this section describes that portion of the design necessary to provide the user the 
capability to access the data on a real time basis. Finally, the last part of this section 
contains the detailed structure of the relational data base design supported by tables of 
data and several sample SQL queries to illustrate ORACLE's data manipulation 


language. 


A. METHODOLOGY OF A RELATIONAL DATA BASE DESIGN 
The phvsical data base is the second stage of the data base design. The logical 
schema (the SDM model) is transformed into the particular data constructs of a 
DBMS. This will be a relational data base design compatible with ORACLE and will 
produce detailed specifications of the data base structure. These specifications will then 
be used during data base implementation to write source statements defining the data 
base structure to the DBMS. 
|l. Terminology 
The basic format used in a relational data base design is a two-dimensional 
table called a relation. The relation, or flat file, containing single-valued entries, is 
constructed of columns and rows of data. The columns are called attributes while rows 
are called tuples. No two tuples in a single relation can be identical. All entries in a 
column must be of the same kind or category, ie., all ships or all names. These entries 
represent possible values for an individual attribute and the range of permissible values 
is called a domain. [Ref. 19: p. 243] 
The terms relation, attribute, tuple, and domain correspond directly to SDM 
terminology. This makes it easier to transpose the SDM schema into a relational data 


base design. Entity classes in SDM may be transposed into relations while SDM 
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member attributes are like tuples. Attribute names in SDM are very similiar to 
relational attributes or columns and STRINGS value classes in SDM directly 
correspond to domains. The distinction in the last case is that tuples are not permitted 
to contain other tuples in relations which is allowed in SDM. [Ref. 19: p. 245] 
2. Design Criteria 

Again, there are no set of rules to follow in all circumstances when creating a 
relational data base design, but there are several criteria for producing an effective 
design [Ref. 19: p. 307]. The first step is to eliminate any modification anomalies. 
These are unexpected consequences that occur when changing data. There are two 
general categories: 


l. Deletion anomaly - this is the loss of information about two entities with only 
one deletion. 


2. Insertion anomaly- this is the gain of information about two entities with one 
insertion. Stated ‘negatively, it means information about an entity cannot be 
inserted until there 15 additional information about another entity. 

These anomalies can be eliminated by creating two new relations called a projection. A 
disadvantage in doing so is that this causes undesirable interrelation constraints since 
two relations share the same attribute. [t is not always possible to eliminate all 
anomalies from a relation, but through the use of “Normal Forms” designers can 
attempt to reach this goal. A normal form is a process that classifies an anomaly and 
then describes a way to prevent it from happening. Refer to Kroenke’s book on Data 
Base Processing, Chapter 8, for a detailed explanation of these forms [Ref. 19]. 

The last two criteria or goals for a relational data base design are relation 
independence and ease of use. If a relation can be modified without regard to another 
then the relation is independent. Ease of use requires that relation structures be 
familiar and seem natural to the user. When all these criteria conflict, as they 
sometimes do, then the designer must assess the priorities and make the best possible 
compromise. 

3. Components and Format 

This section defines the three major components of a relational data base 
design; relations, domains and attribute/domain correspondences, and interrelation 
constraints [Ref. 19: pp. 311-321]. The first component specifies the name, attribute, 
and key of the relation. The generalized format is displayed in Figure 4.1. In addition, 
the relation table will contain four to five tuples of example values from the domain 


associated with each attribute. The order of the values listed will match, one-to-one, 
















RELATION_NAME (attributel, attribute2, ...) 
Key(s): relation attribute 







Attribl Attrib2 Attrib3 Attrib4 Attrib5 Attrib6 


e 1 | | | — 
Ecc iii 
ee — —1 — —1] — ke 
Luce ei —1- — 


Figure 4.1 Format for relations. 


the order of the listed attributes. Each defined relation will be listed in separate figures 
compared to onlv one figure for the remaining components. The second component 
specifies domains and attribute/domain correspondences for the entire relational data 
base design. Domains are defined both physically and semantically because it 1s 
possible that two domains will have the same appearance but have very different 


meanings. The structure for this component is depicted in Figure 4.2. This table will 


Domain Name Format and Meaning 


numeric YYMMDD 
SEET integer less than 10 


AR(10); names of ships 


Attribute 


RELATION. attributel 
RELATION. attribute2 





Figure 4.2 Format for domains and attribute/domain correspondences. 


contain the complete list of domains and attribute/domain correspondences within the 


Relational Data Base Design. The final component structure, which specifies 
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interrelation constraints, is listed in Figure 4.3. These components are the minimal 


ones and can be augmented by additional documentation for clarification. 


SE 1 ' J / 07 


attribute3 attributed 





Figure 4.3 Format for interrelation constraints. 


B. A RELATIONAL DATA BASE DESIGN FOR THE C2 WORKSTATION 

The relational data base design is very similiar to the design used at the Naval 
Ocean Svstems Center (NOSC) in San Diego, California. What makes it different, 
besides being tailored to the needs of the Naval Postgraduate School (NPS), is the 
additional real time requirement to access data during game play. 

1. Description of the System Used by NOSC 

The system at NOSC extracts the data in a sequential manner. It goes to each 

table, extracts the data and then moves onto the next set of data items. This data is 
then sent to tape and run through their TAPE PIPE.EXEC program to organize the 
data into six files. The data is then shipped to their own workstation, an HP 9020, and 
loaded into their relational DBMS, INFORMIX. At this time, NOSC is using the data 
strictly for post wargame analysis. The Naval Postgraduate School will also use the 
data for post game analysis, but at the same time, NPS wants to permit players of the 
wargame to access this same data during game execution. This requires a different 
design for the ORACLE DBMS. 

2. Implementation Requirements for the NPS DBMS 

To accommodate this plan, NPS will have to develop their version of NOSC’s 

TAPE_PIPE.EXEC program to organize the data. This program only works when 
using a tape as an input. NPS will use a disk storage device instead of a tape. After the 
data are run through this program, they will be sent to the Sun workstation via the 
ETHERNET, which is a 10 Megabit-per-second coaxial cable local area network 


facility [Ref. 21: p. 10], and written to a disk file. This will require a second program to 


"The author obtained this information through a telephone conversation with 
personnel from NOSC. 
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format the data for transmission over the net. 

Once information is on the disk, it is then necessary to reformat the data into 
ORACLE terms for entry into the appropriate relational table. The design of these 
tables will correspond to the way the data are extracted from the RESA data base. 
Too many changes or additions in the original design would require a modification of 
the initial program which extracts the data. This should not be necessary. At this time, 
the relations are logically structured. Only through use of the system, or if the 
requirements change, will it prove necessary to make changes in the current 
organization of the data base. 

3. Design Requirements to Assure Real Time Data Access. 

lo permit the user to access this data during plav of the game the DBMS 
should be set up into duplicate relational tables. Instead of the initial six tables used 
at NOSC, there would now be 12. Only the names and the amount of data. not the 
type, would be different. As data are received at the workstation and converted into 
ORACLE format, they would be written to 12 relational tables. The first six tables 
would contain the complete set of information retrieved. These would be the historical 
files. The second six would contain only the most recent update of information 
provided from the game. The advantage of this arrangement is it reduces the time to 
retrieve data from the system. The current will be much smaller then historical files, 
and therefore, require less time to search. 

Information is collected once during each game cycle (one minute of game 
play) for all six relations, sometimes more if the information involves the remote 
detection of targets. Then, during the next game cycle, this information is collected 
again. It may have changed or their may be additional data or some data mav have 
been deleted. Each game cycle will be kept in the historical files. Only the data in the 
last one to five game cycles will be kept in the second set of relational tables. As new 
information is written to the table, those records with the oldest game time will be 
deleted which eliminates any problems that would normally arise due to modification 
anomalies. This keeps the access time down to a minimum when querving the data. 
These tables can grow very large in size depending on the length and complexity of the 
wargame. Required storage may run anywhere from 55 to 100 Megabytes of disk 


space.’ 


“This was recommended by NOSC. 


Potential storage requirements were identified by NOSC. 
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There is one other item of importance concerning the program that extracts 
the data from the blackboard. The program keeps control of data by using a game time 
and slot number for all records of data extracted from the game. There is a unique slot 
number for every record extracted within the same game cycle. As such, there will be 
two additional attributes listed in each relation; one for a slot number and one for a 
game time. Only six tables are listed but 12 will be required during implementation of 
the system. The format, which is the same for both sets of relations, is displayed in 
detail in the next section. 

4. Relational DBMS for the C2 Workstation. 

The format used to depict the relational design consists of three sections. The 
first identifies the individual re/ations, which will be duplicated in the implementation 
phase. The other two sections, domains and attribute{domain correspondences and 


interrelation constraints will be used to define the fields of the attributes in the DBMS. 












REMOTE DETECTION (unit_detected, apparent-latitude, apparent_longitude, 


slot_number, game_time) 


Key(s): Unit detected + slot number + apparent latitude + apparent 


longitude + game time 


Note: Name and slot number can be repeated more than one time in a game 





cycle depending on which unit detected the target. Therefore, both unit 
detected and slot number are multivalued with respect to game time. 


unit apparent apparent slot game 
detected latitude longitude number "time 


BF201 72 45N 55 68E 


BK102 56 32N 24 12W ME t 


















Figure 4.4. Relation REMOTE DETECTION. 
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ACTIVE_UNIT (name, status, view, type, assigned_target, bomb_hits, 


missile_hits, slot_number, game_time) 
Key(s): Name + game_time 


Note: 1. Bomb_hits and missile_hits are multivalued with respect to name. 


2. Name is multivalued with respect to game time. 


| assigned bomb missile slot game 
status view type target hits hits number time 





Figure 4.5 Relation ACTIVE UNIT. 
















TRUE POSITION (name of unit, true latitude, true longitude, slot number, 


game time) 
Key(s: Name of unit + game time 


Note: Name is multivalued with respect to game time. 







name. apparent apparent Slot game 
of unit latitude longitude number time 


[xu | sas | sw | 4 |] —» - 


Figure 4.6 Relation TRUE POSITION. 


39 


'NOLLVIAGIOANI OUNVNAC Yonepy  L'p andi 


2141 42quunu ) ۸ juapt 23817 2511)? رر ری‎ 351:1/10( adpiupp anou 
22 10]5 jan{ opisdol DS "HT 2401$ 





"oun aurea 03 192dS91 YI poan[eAn[nul sr 3UuleN! "C 


ULU O} 15adso1 (ira ponjeAnnur 34e SuiureuroJ pu? uoneornnuop] ^|. NON 


oui ouled -- uonvopnuuoepr 4 AB, "Ia 


(Sun ouied 'joquinu  10|[s 'Burureuro *uorvorjnuopt 


'edeurep ]onj 'edeurep opisdoi 'o3eurep wes “93ewuep nu 'odeuiep 21015 *surru) NOILLVIVMIOANI OIINFNAG 





40 


HOVINVOG CELLOF TINI uonrios | Sit onèt 


“aj St 
ST T 
سوب جس‎ 


1 | 0 m 0 or | NF 


ST 
=f 


Er 3 T 
PEN NU oe o: | o o | o] s 
"mx 
NET 





240) — 4quuu paads snis — mon  o2onop fno ءریں:‎ ا١‎ yous ans 04018 jonf 3:00 ر35‎ 1/۲ nun 
ouvè 10]5 1d24 aquiu daa MIDS l a1111 adoUWP 


aui otued 0] 103dso1 tr panpan st yun poer °C 


"un Padeuwp 01 1»2ds21 ts pon[pAnntu sr adeurep Jo oun] ^|. NON 


MUN AV + oSetuvep Jo oun + wun pasewurg :(s)foy 


(oum ouie8 '1oquinu  10[s ‘poods ‘smivis yodas ‘vata ‘saotaap goquinu ۶111.1311 


"Wa]sAs uodeam “Furyuis ‘soys tues “sa1015 “janj “asrq “un” poBouwp 'advurp jo oun) JOPIVEG GILOTTINI 


4l 


“VLVO INTIS OVON PE UORPPYy GF 181] 


۶" ۹۹ ۶۲ | 
alee S 0 
ASE 9c OF 0 


AVC 
Mit 


1 Wi an ids | IOLA 
a xuud | 001:1A 








C4 C1 CH 





E ENS 0 C t t 0 LOLITA NE EIS) 

elo 1 faseie] asecz| Her cC | NECCC| 0 c c o | orsaf ۹۵۹ 
out  4quu duo) inj suo] n] DAN) )لد‎ IS 220p Mat mIs my pouf 102401. pouf nun 
auv? Jor BAD} BAD} nun nun qoid ںہ‎ BAD) qoid aqu $544 aspaua 


‘AU oue 0) IOAadsal YILW PonTRANyNu ae gun 3uiBeduo jo oumu pue 193Je | “€ 
iun 3uide3ua JO aweuU 0) 29dSa1 YIM PaNfRAN|N dP pai sopissmur 1oquinu pup o[isstu addy] 2 


338101 01 لہ ل153‎ (pir pon[eAngnur sr dun gurideduo JO JWEN “| :910N 


MUN OUP + aun ojs + HUN 3urideduo JO UPN :(s)fay 


(oum oua '1j2quunu 10[s 
'epniiSuo[ 193181 “pame 193121 'aopniiduo] nun *opmine nun 993181 Muy qoid 
“adAj] 3231e] ‘snes 19317] 'po1oa1op “AavotA “smnas “np qoad “pouy sapissmu 60 


“aissmu jo 19311 poudisse “Pann opisstur ada un Bursesua jo aueu) ٣7۲۴ ۸337ی‎ 


Domain Name 
DAMAGE 
DISPOSITION 
INDICATOR 


ITEM. NAME 
MAX, SPEED 


MINUTES 

NUMBER, EPU 
NUMBER, FIRED 
NUMBER ITEMS 
PARKED AIRCRAFT 
PERCENTAGE 
POSITION. LATITUDE 


POSITION LONGITUDE 


REPORTING 


SENSORS_DAMAGED 
TYPE_MISSILE 
TYPE_UNIT 


UNIT_NAMES 
UNIT_STATUS 
YES 


Figure 4.10 


Format and Meaning 


integer, 0 to 2; identifies condition of target after 
engagement. Integers are defined in BBCODE.def 
table 6.12 in RESA’s data base. 


integer, 1 to 10; identifies unit as friendly or hostile 


integer, 0 or 1; flag identifys specific areas where unit 
sustained damage 


CHAR(10); names of items attached to a unit 

integer, 0 to 60; maximum speed (knots) of a 

damaged ship 

integer, 0 to 65000; game time when unit was 
amage 

integer, 0 to 200; explosive power units (EPUs) a unit 

may receive during current game cycle. 

integer, 0 to 10; number of air-to-air or surface-to-air 

missiles fired by a unit 


integer, 0 to 5000; equipment or weapons available 
on a unit 


integer, 0 to 1000; number of parked aircraft that 
were damage 

real number, 0.0 to 1.0; identifies amount of damage 
or probability of hits on a unit 

LLMMSSX; where LL is an integer 0 to 90, MM 
(minutes) is an integer 0 to 60 NEUE Is an 
integer 0 to 60, X is à CHAR whose value is N, E, S 
or W. Position is given in degrees. 


LLLMMSSX; where LLL is an integer 0 to 180, 
MM (minutes) is an integer O to 60, (seconds) 1s 
an integer 0 to 60, X is a CHAR whose value is N, 
E, S or W. Position is given in degrees. 


integer, 0 to 7; indicates status of report for damaged 
units. Integers are defined in BBCODE.def table 6.18 
in RESA data base 


integer, 0 to 24; number of sensors that were 
damaged on a unit 


CHAR(8); names of missiles launched from an 
aircraft or ship 


integer, 0 to 11; classifies unit, for POPE ship or 
aircraft. Integers are defined in BBCODE def table 3.0 
in the RESA data base 


CHAR(8); names of ships, aircraft flights, shore 
bases, and cruise missiles 


integer, 0 to 9: current condition of unit. Integers are 
defined in BBCODE.def table 5.6 in RESA data base 


integer, 0 or |; indicates if unit has been detected 


Domains of relational attributes. 
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Attribute 


ACTIVE_UNITS.name 

ACTIVE UNTTS.status 

ACTIVE UNITS.view 

ACTIVE UNITS.type 

ACTIVE UNITS.assigned target of unit 
ACTIVE UNITS.bomb hits 

ACTIVE UNITS.missile hits 

ACTIVE UNITS.slot number 

ACTIVE UNITS.game time 


REMOTE DETECTIONS.apparent latitude 
REMOTE. DETECTIONS.apparent longitude 
REMOTE DETECTIONS.name of unit detected 
REMOTE DETECTIONS.slot number 
REMOTE DETECTIONS same aime 


TRUE_POSITION.tme_latitude 
TRUE POSITION.true longitude 
TRUE POSITION.name of unit 
TRUE POSITION.slot number 
TRUE POSITION.game time 


INFLICTED DAMAGE.time of damage 
INFLICTED DAMAGE.damaged unit 
INFLICTED DAMAGE base 
INFLICTED_DAMAGE fuel 
INFLICTED _DAMAGE.stores 
INFLICTED DAMAGE.sam sites 
INFLICTED_DAMAGE. sinking 
INFLICTED DAMAGE.weapon system 
INFLICTED_DAMAGE. aircraft 
INFLICTED_DAMAGE.number_devices 
INFLICTED_DAMAGE. view 
INFLICTED DAMAGE report status 
INFLICTED DAMAGE.speed 
INFLICTED DAMAGE slot number 
INFLICTED DAMAGE.game time 


Domain 


UNIT NAMES 

UNIT STATUS 
DISPOSITION 

TYPE UNIT 

UNIT NAMES 
NUMBER EPU 
NUMBER EPU 
CONTROL NUMBER 
CONTROL NUMBER 


POSITION LATITUDE 
POSITION LONGITUDE 
UNIT. NAMES 
CONTROL NUMBER 
CONTROL NUMBER 


POSITION LATITUDE 
POSITION. LONGITUDE 
UNIT. NAMES 
CONTROL NUMBER 
CONTROL NUMBER 


MINUTES 

UNIT. NAMES 
INDICATOR 
INDICATOR 
INDICATOR 
INDICATOR 
INDICATOR 
INDICATOR 
PARKED AIRCRAFT 
SENSORS DAMAGED 
DISPOSITION 
REPORTING 

MAX SPEED 
CONTROL NUMBER 
CONTROL NUMBER 


Figure 4.11 Attribute/Domain correspondences. 
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Attribute 


DYNAMICS INFORMATION.name 
DYNAMICS INFORMATION .;store damage 
DYNAMICS INFORMATIO N:hull damage 
DYNAMICS INFORMATION.sam damage 
DYNAMICS INFORMATION.topside damage 
DYNAMICS INFORMATION fuel damage 
DYNAMICS INFORMATION identification 
DYNAMICS INFORMATION remaining 
DYNAMICS INFORMATION.slot number 
DYNAMICS INFORMATION.game time 


ENGAGEMENT DATA.name of engaging unit 
ENGAGEMENT DATA.tvpe of missile fired 
ENGAGEMENT DATA.number of missiles fired 
ENGAGEMENT DATA. probability-hit 
ENGAGEMENT DATA.status 
ENGAGEMENT DATA.view 

ENGAGEMENT DATA.detected 

ENGAGEMENT DATA.target status 
ENGAGEMENT DATA.target type 
ENGAGEMENT DATA.probability hit target 
ENGAGEMENT DATA unit latitude 
ENGAGEMENT DATA unit longitude 
ENGAGEMENT DATA.target latitude 
ENGAGEMENT DATA.target longitude 
ENGAGEMENT DATA slot number 
ENGAGEMENT DATA.game time 





Domain 


UNIT NAMES 
PERCENTAGE 
PERCENTAGE 
PERCENTAGE 
PERCENTAGE 
PERCENTAGE 
ITEM. NAME 
NUMBER ITEMS 
CONTROL NUMBER 
CONTROL NUMBER 


UNIT. NAMES 

TYPE MISSILE 
NUMBER FIRED 
PERCENTAGE 

UNIT STATUS 
DISPOSITION 

YES 

DAMAGED 

TYPE UNIT 
PERCENTAGE 

POSITION. LATITUDE 
POSITION. LONGITUDE 
POSITION. LATITUDE 
POSITION LONGITUDE 
CONTROL NUMBER 
CONTROL NUMBER 


Figure 4.11 Attribute/Domain correspondences. (cont’d.) 


There are no interrelation constraints listed for this relational data base design. 


Interrelation constraints usually occur when entity classes are subclasses of other entitv 
classes and when domains themselves are entity classes. In this case, the domains listed 
for each member attribute were defined as character STRINGS and not other entity 


classes. 
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5. Sample Data Base Queries 

This section serves two functions. First, it ties the SDM and the Relational 
Data Base Design together. Several queries are made on the previously defined 
relations in order to demonstrate what the analyst or player will be able to extract from 
the data base. In addition, it explains how ORACLE’s data manipulation language, 
SQL is used to retrieve data. 

a. Basic ORACLE SQL Commands 

The basic SQL commands are SELECT, CREATE, and INSERT. SELECT 
retrieves rows of data from a table, CREATE defines a new table, and INSERT enters 
rows of data into a table. The SELECT command is used for data base retrieval. It is 
the most common operation done with ORACLE. The basic SELECT command has 
two parts, called clauses; 
l. The SELECT clause - lists the columns from the table to be retrieved. 
2. The FROM clause - names the tables where the columns are located. 

The SELECT clause is alwavs entered first and immediately followed by the FROM 
clause. These two commands would display all rows of information from the table. In 
order to select only specific rows of data, a WHERE clause must be added to the basic 
statements of SELECT and FROM, as demonstrated in Appendix B and in the next 
section. The WHERE command causes ORACLE to search the data in the table and 
retrieve only those rows that meet a search-condition. These conditions are varied by 
using AND, OR, BETWEEN and other clauses provided by ORACLE as clarifying 
statements. If more than one table of data needs to be queried for the information, 
then ORACLE will use a JOIN command to obtain the data. [Ref. 22] 

b. User Types of Queries 

These queries support two kinds of information retrieval. Figures 4.12 and 

4.13 describe questions of possible interest to an active player of the RESA wargame 
who would be using the workstation as DSS. The second type of information is 
characteristic of a question an analyst using the system might ask (Figure 4.14). It 
should be noted that each of the three figures uses a different SQL format for 
retrieving the data. They are a normal SELECT query, a subquery using two different 
relations, and a JOIN query, which pulls the information for the final answer from 
more than one table. This is different from a subquery. A subquery may conduct 


Operations on multiple tables, but it obtains the final answer only from one table. 
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Question: What is the last known position and time for the Soviet submarine 
Gulf1? 


SELECT (unit detected, apparent latitude, apparent longitude, game time) 
FROM (remote detection historical) 
WHERE unit detected = gulfl 


AND game time » 58 


Result: 
unit apparent apparent game 
detected anida olaa time 
Gulf 32 22N 24 36E 44 
Gulfl DS OIN 23 6E 45 


Note: Current game time is 54. The user had to access the historical 
data table to be sure of obtaining an answer since current tables 


only contain data from the last few game cycles. 


Figure 4.12 Player SQL sample 1. 


47 


Question: How much air activity has been detected over Petro? 


SELECT {count (distinct unit_detected)} 
FROM (remote_detections) 
WHERE (apparent_latitude, apparent_longitude) = 
GROUP BY game_time 


SELECT (true_latitude, true_longitude) 
FROM (active_unit) 
WHERE name = Petro 
AND game time > 45 
AND true latitude BETWEEN (true latitude + 2 
and true_latitude - 2) 
AND true_longitude BETWEEN (true_longitude + 2 


and true_longitude - 2) 


Result: 
game_time unit_detected 
46 23 
47 “26 
48 29 
49 30 


Note: Current game time now equal to 49. 


Figure 4.13 Player SQL query number 2, (subquery). 
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Question: What is the average consumption of SAMs for the VINSON class 
of ships during the first 10 minutes of combat (once incoming cruise 
missiles have been detected) and the total number of successful 


intercepts of these missiles. 


SELECT (active unir.type. count (active unit.type) 


avg (dyn_info.remaining), sum (engage_data.target_status)} 


FROM {dynamic_information, engagement_data, active units) 


WHERE active_unit.type = 3 
AND active_unir.slot number = dynamic_information.slot_number 
AND dynamic information.identification = SAM 
AND engagement_data.game_time BETWEEN (engagement_data.game_time 
> = 32 and engagement_data.game_time < = 41) 
AND engagement_data.target_tvpe = 5 
AND engagement_data.target_status = | 


AND engagement_data.unit_name = active units.name 


Result: 

active units count avg(dyn info sum(engage data 
type (active_units) remaining target status) 
3 4 7 Vi 


Note: [t is assumed one knows the initial quantity of SAMs. 





Figure 4.14 Analyst SQL query sample, (JOIN). 


C. SUMMARY 

Chapter IV described methodology used to develop the Relational Data Base 
Design for the C2 workstation. This involved mapping the SDM to the relational 
DBMS, ORACLE, which NPS chose for their C2 workstation. The basic components 
of this design are relations, domains and attribute/domain correspondences, and 


interrelation constraints. The second major section of this chapter identified the current 
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system used by NOSC and how NPS's system would have to be constructed in a very 
similiar fashion. Two additional programs need to be developed. The first program is 
required to organize the data into six tables after it is extracted from the RESA 
wargame. The second program is needed to format the data in order to transmit it from 
the RESA wargame to the workstation via the ETHERNET. It was suggested that two 
sets of relational tables be implemented in the data base to permit the user to access 
the data during game execution. The first set would contain historical files for post 
game analysis, while the second set of tables would contain only those records from the 
most current game cycle. These tables were described in detail and used to construct 
several sample SQL queries to illustrate the types of information which can be 


extracted from the data base. 
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V. SUMMARY 


A. REVIEW OF THE PROBLEM 

This thesis supported the Naval Postgraduate School’s (NPS) research into the 
development of a multimedia (text, voice, graphics), command and control (C2) 
workstation as a Decision Support System (DSS) to aid players of the Research, 
Evaluation, and System Analysis (RESA) facility. The problem involved interfacing the 
the C2 workstation to RESA to support post game analysis of the data and to permit 
players of the wargame to access real time data during game execution. This coincided 
with the Navy's overall problem of obtaining a workstation flexible enough to work 
with a wide variety of C2 systems and adaptable enough to meet the requirements of a 
diverse set of users. This meant using both voice and keyboard natural language 
interfaces on the workstation. 

With this understanding, the NPS chose the Sun microsystems’ version of UNIX 
and ORACLE, a relational data base management system (DBMS) to function as the 
C2 workstation. The primary reason is that it supported a wide variety of multimedia 
functions including voice capability in the near future. NPS's long term goal is to use 
this workstation to provide plavers and analysts the capabilitv of real time data 
extraction by using a voice, natural language interface to operate the system. As such, 
it was the goal of this thesis to define the boundaries of the problem and propose a 
data base design for the Sun workstation using data supplied by the Naval Ocean 
Systems Center (NOSC). 


B. CONCLUSIONS 

If it is assumed the RESA data is a good representation of data arriving from 
Operational systems, then it is possible to make several conclusions in using the Sun 
workstation as a DSS. 


1. It is possible to define a data element dictionary for a military environment 
using the design of industry standard DBMS systems. 


2. A duplicate set of relational tables can be defined to store historical data and 
current data to allow a microsystem to operate as a DSS. 


3. The design of the DSS may allow real time retrieval of aggregated data, in 
response to user SQL or natüral language queries, if the hardware and software 
operating speed is sufficient. 


4. It is possible to use a dedicated processor for off-line retrieval of data from an 
Operational system. 
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5. A series, of logical steps can be defined to develop a natural language interface 
to benefit infrequent users of the DSS. 

C. RECOMMENDATIONS 

After analyzing the data and conferring with people at NOSC, we recommend 
that the relational data base design be structured in accordance with the way data are 
extracted from the RESA wargame. It is already organized into logical tables and this 
will minimize the initial amount of work required to implement the system. Those 
changes in the design that did occur were in support of NPS's decision to use the C2 
workstation in the additional role as a DSS. Therefore, we recommend that two sets of 
relational tables be maintained in the DBMS on the workstation. The first set would 
contain all data extracted from the wargame scenario, while the second set would be an 


abbreviated file containing those records extracted from the last few game cycles. 


D. RECOMMENDATIONS FOR FURTHER STUDY 
The relational data base design is just the first step in the total research program 
in progress at NPS. Five additional programs were identified that need to be developed 
before this project can be completed. These include: 
l. DISK PIPE.EEXEC program - is required to replace | NOSC's 


TAPE PIPE.EXEC program. This is needed to clean up the data after it is 
extracted from the wargame and to organize the data into the six logical tables. 


ty 


An ETHERNET program module - this second program module is required to 
oun the data in order to transmit it over the ETHERNET to the Sun 
workstation. 


ORACLE interface module - once the Sun workstation receives the data it must 
be reformated again in terms of ORACLE so it can be written to the 
appropriate files. 


فیا 


4. Menu driven module - the author recommends a menu, driven interface be 
developed to assist the user in retrieving information from the data base. 
Although ORACLE uses SQL for this process the user must still be familiar 
with the data base organization for this method to be effective. 


یں 


Natural language module - the ultimate goal of the svstem is to access the data 
via a natural language. It is due to the difficulty that will be encountered in 
developing this module that the menu driven interface was proposed as an 
interim solution to access the data base. 

The first three programs should be considered as components of the larger project to 
interface the Sun workstation to the RESA facility. Once this stage is complete then 
the relational data base design can be implemented on the workstation using ORACLE 
as the DBMS. The next stage, developing a menu driven query program (as an interim 
solution until a natural language can be developed) is considerably larger in scope then 


the first three. As stated previously, menu driven interfaces require less memory and 
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appear well suited to command and control queries. The natural language program is 
the largest and most difficult task to be accomplished in the future. However, it offers 
the potential to reduce the learning curve for players using the system. It will aid the 
infrequent user in accessing data and in making queries that would be difficult to define 
in SQL. The payoff from this type of C2 system, with these capabilities, is a more 
robust approach to distributed command and control [Ref. 4: p. 1]. 


E. POTENTIAL PROBLEM AREAS 

There are several potential problems that may hinder the implementation of the 
proposed relational data base design and affect its efficiency when the workstation 
becomes operational. The biggest concern lies with the processing capability of the Sun 
workstation. Is it fast enough to handle the volume of data being transmitted from the 
RESA wargame within the designated one minute cycles? It is understood that the 
ETHERNET will ultimately control the maximum rate at which data 1s transmitted to 
the workstation, but will it be so busy accepting and receiving data that it will be too 
slow in performing any other function? The total quantity of data retrieved (rom one 
game lasting 75 minutes, can require anywhere from 55 to 100 Megabvtes of disk 
storage. Even breaking down the data into one minute sections averaging just one 
Megabyte of information would still require a great deal of processing time. Multiply 
this number by the series of steps listed above and it becomes easy to understand how 
the system may not be unable to support and process such a large amount of data in a 
timely manner. 

A second issue, related to the first, is how “real time” the DSS will be in accessing 
the data. There may be so much data that it will be infeasible to update the current 
relational files every game minute. [t may be necessary to extend this time to two or 
three minute cycles. How effective would calculations be if they were made from data 
obtained only every 2 or 3 minutes, especially when RESA can lengthen the game cycle 
time at random. How then, would this affect the players using the workstation as a 
DSS? 

A final issue concerns the size of the overall data base collected for each 
wargame. Although the relational data base is a two dimensional flat file it 1s 
convenient to think of it as a three dimensional file with the third dimension being 
time. At game time = l the data base consists of single values for every data element 


in the program. At game time = 2 the data base grows to two values for every data 
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element. With the data base growing with each time cycle it is easy to see that this 
process will generate a very large and possibly unmanageable data set in a very short 
time. There are several possible approaches to this problem which take advantage of 
the fact that not all data changes each time and that not all data must be saved. This 
leads into the idea of adding temporal semantics into the DBMS. Significant savings in 
data base size and processing speed could be achieved just by processing data which 
has changed since the last game time. We feel this area is worth further study since it 
offers a potential solution for all three identified problems. 

These problems are going to be compounded as NPS expands the network by 
adding workstations. Not only will Sun stations be used but also existing HP 9020s. As 
such, the interface to establish correct protocol procedures between these two systems 
must also be addressed and developed. 

The final problem area which will affect the continued performance of the Sun 
workstation is NPS's ultimate goal to eventually tie this system into the Defense Data 
Network (DDN). This will allow direct interface with the RESA wargame located at 
NOSC. If this can be accomplished then these systems should be able to operate in a 
similiar environment from ship-to-ship or shore. 

[n summary, there are a large number of questions that still need to be answered. 
This paper defined the project in concrete terms and proposed a relational data base 
design for the workstation based on work completed at NOSC. Problems were raised 
which need to be resolved before further work can continue while others will resolve 
themselves as the system becomes operational. Feedback provided by the players in the 
game will greatly enhance the effectiveness of the system as a DSS. If the system really 
is evolutionarv, as all DSSs are supposed to be, then it will be able to meet the 
proposed changes in design and accommodate new systems such as the HP 9020 and 
the system at NOSC. 
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APPENDIX A 
SUN WORKSTATION 


This section describes the system selected by the Naval Postgraduate School to 
be used as the Command and Control Decision Support System to support RESA. 
There are two basic components; the Sun Workstation using Sun’s version of UNIX 
Operating system, and ORACLE, the Relational Data Base Management System 
(RDBMS). 


l. SYSTEM HARDWARE 

The Sun-3 product family is a group of 32-bit systems based on the Motorola 
MC 68020 CPU chip and the high-speed 32-bit VMEbus. It comes with a standard 2 
Megabytes of real memory expandable up to 16 Megabytes and can address up to 256 
Megabytes of virtual address space. The svstem includes a floating point accelerator, 
graphics processor board, and graphics buffer. The floating point accelerator runs up 
to four times faster than the MC68881 and gives two times the performance of a 
VAX780 using a floating point accelerator. The accelerator complies with the IEEE 
754 version 10 standard and supports both 32-bit and 64-bit floating-point operations. 
The graphics board can render 40,000 2D vectors per second or 25,000 3D vectors per. 
second. The graphic buffer augments the graphics board and is intended for 
applications where 3D transformations and hidden surface remove is time critical. This 
combination can shade and remove hidden surfaces of 3D polygons faster than one 
million pixels per second or up to 35 million pixels per second for arbitrary polvgons. 
Peripherals that can be attached to the system include SMD disks ranging in size from 
84 Megabytes to the 474 Megabyte “Eagle” disk, a nine-track disk a one quarter inch 
cartridge tape, and SCSI disks and tapes. All systems communicate via the 
ETHERNET which is a 10 Megabit-per-second coaxial cable local area network 
facility. [Ref. 21: pp. 7-10] 


2. SYSTEM SOFTWARE 

The Sun Workstation runs an enhanced version of the 4.2BSD UNIX system 
derived from the University of California at Berkeley. The system provides support for 
interprocess communication and local area networking. The UNIX svstem is equipped 


with a host of software as a base level package. Supported languages are Pascal, C, 
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FORTRAN 77, and Assembler. There are utilities for performing statistical text 
processing and document preparation. In addition to the utilities package Sun has 
added User Interface package based on overlapping windows, and a graphics package 
to support the more common graphics standards. [Ref. 21: p 3] 

a. UNIX 

The operating system uses a hierarchical file system to group related files 
within a directory. A directory is simply a special case of file. Sun Microsystems have 
taken this idea one step further into a Network File System. This is a facility for 
sharing files in a heterogeneous environment of machines, operating systems and 
networks. Sharing is accomplished through a remote file system rather then reading or 
writing files in place. This avoids the problem of each node maintaining their own file 
system and thereby duplicating resources. 

There are two main shells on the Sun operating system. They are the C Shell 
in the command interpreter part of the 4.2 BSD operating system and the Bourne Shell 
which is the UNIX version 7 command interpreter. The two major external differences 
between the two shells is that the C Shell provides job control and history. Job control 
allows jobs to be run in the background or foreground. The history facility is used for 
reissuing previous commands. The number of commands possible is specified bv the 
user. Major features that both shells provide to the user interface are 

l. Analvsis of the command line. Run the indicated command, passing the 
remainder of the command line as arguments to the command. Each command 
is run as a separate process. 


2 mus shells can redirect the standard input, output, and error files as defined by 
e user. 


3. Can connect multiple processes together via a "pipeline." The standard output 
of one process is connected to the standard input of the next process in line. 


4. File name expansion. Metacharacters are provided to indicate aggregates of 
tiles. Matches can be made on single characters or strings of characters in a 
filename. 

5. Both shells provide user-defined search paths for finding commands. 

Both shells can be used as a programming language. The syntax of the C shell 
commands resembles the C programming language whereas the Bourne Shell resembles 
Algol-68. [Ref. 21: pp. 35-37] 
b. Window Utility 
Sun View is the Sun Visual/Integrated Environment for Workstations. It has 
two components; a User Interface and a Sun Guide. The Sun Guide is a programming 


interface accessible via a collection of subroutine libraries. The user interface provides 
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multiple overlapping windows on the screen and each window runs independently of 
the other. It is a collection of software utilities that exploit the graphical capabilities of 
the Sun hardware. It uses a mouse as a pointing device as the primary mechanism for 
interacting with the tools. This avoids having to type in a response and having to wait 
for a response. Windows can be moved around the screen as needed and when closed 
becomes an “icon”; a small graphical object whose appearance sometimes suggests its 
function. Some of the features provided bv the Sun Window System are a shelltool. 
iconedit, and mailtool. The shelltool provides a window-based interface to the 
standard UNIX svstem command interpreters. [conedit is used for designing icons and 
cursors. Mailtool interfaces to the standard mail reading facility. [Ref. 21: pp. 21-31] 
c. Mail Utility 

The Sun station supports two tvpes of mail routines; electronic mail and 
electronic message. Electronic mail is similiar to sending a telegram. It can be read, 
saved or edited. Electronic mail can be sent to the same machine, over a local network 
Or remote network. An electronic message is like calling someone up on the phone. 
The person who receives the message can replv to it while the user waits. There are 
four types of electronic messages; same machine, local network, broadcast, and svstem, 


which are messages the svstem sends to the user's console. [Ref. 23: pp. 3-4] 


APPENDIX B 
ORACLE, A RELATIONAL DATA BASE MANAGEMENT SYSTEM 


ORACLE is relational database management system plus a complete set of 
integrated software tools for application development and decision support. These tools 
include an 


l. Application generator - this helps the user define an application by leading 
them through a simple question and answer dialogue. 


2. Report generator - allows the creation of both production and ad-hoc reports. 
It will automatically format anv, SQL query into a report with columns and 
headings taken from the data dictionary. 


3. Color graphics - permits display of data in color, in the form of pie or bar 
charts, and multi-line plots. 


4. Document preparation - lets the user interleave the results of multiple data base 
queries with text and graphics into a single formatted report or document. 


Un 


Integrated data dictionary - contains all the information about tables 
applications, reports, and graphs and is automaticallv updated by the system as 
new tables and applications are added to the data base. 
Data is displayed in a two-dimensional table and is accessed via a standard user 
interface, SQL (pronounced see-quel). SQL is an English-like language that can be 
used directly from the terminal or embedded in standard programming languages. SQL 
includes commands for 

1. Query - retrieving data from the data base. 

2. Data manipulation - inserting, updating, and deleting data. 

3. Data definition - adding new tables. 

4. Data control - preventing access to private data. 
SQL specifies operations in terms of what is to be done and not how to do it. [tis a 
nonprocedural language. 

The basic SQL commands are SELECT, CREATE, and INSERT. SELECT 
retrieves rows of data from a table, CREATE defines a new table, and INSERT enters 
rows of data into a table. The SELECT command is used for data base retrieval. It is 
the most common operation done with ORACLE. The basic SELECT command has 
two parts, called clauses; 

l. Ihe SELECT clause - lists the columns from the table to be retrieved. 


2. The FROM clause - names the tables where the columns are located. 
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The SELECT clause is always entered first and immediately followed by the FROM 
clause. These two commands would display all rows of information from the table. In 
order to select only specific rows of data, a WHERE clause must be added to the basic 
statements of SELECT and FROM. The WHERE command causes ORACLE to 
search the data in the table and retrieve only those rows that meet a search-condition. 
These conditions are varied by using AND, OR, BETWEEN and other clauses 
provided by ORACLE as clarifving statements. If more than one table of data needs to 
be queried for the information, then ORACLE will use a JOIN command to obtain the 
data. This command combines the data selected from multiple tables into a single 


table for display to the user. A sample query using SQL is depicted in Figure B.1. 


SELECT (name, job, salary) 
FROM (employees) 
WHERE job = technician 
AND salary > 2800; 


Resulting table: 
NAME JOB SALARY 


Harris technician 2975.00 
Terrill technician 2850.00 





Figure 8.1 SOL sample query. 


Another important feature of ORACLE's SQL query language is its complete set 
of arithmetic and string functions. The arithmetic operators include adding, 
subtracting, multiplication, division, exponentiation, rounding, truncation, and absolute 
value. String functions include concatenation, translate, string length, substring, 
instring, upper case, lower case, and sound matching. These are only partial listings of 
the total capability. 

Information on ORACLE was provided by the ORACLE Corporation in their 
book ORACLE Overview and Introduction to SQL [Ref. 22]. 
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APPENDIX C 
RESA BLACKBOARD DATA 


The Naval Ocean Systems Center (NOSC) provided the data used in the data 
base design. After it is run through the TAPE PIPE.EXEC program it is separated 
into six separate files corresponding to RESA tables. This section lists a portion of 


each of those files (for one game time slot only) and their associated fields. It also 


Data [tem Field Name 


Name 

Missile ms 
Assigned Target 

end Fired 

Probability of Hit 

Status 

View 

In Use 

Detected 

Status of Target 

Type of Target 

Probabilitv Hit Target 

Latitude of Unit 

Longitude of Unit 

Latitude of Target 

Longitude of Target 

Pointer 

Length of Entry in Blackboard 

Base of Table 

Pointer Index 

Slot Number 

Game Time 


++++2 


M Ga) Eech Een Esc 
= GIO 





Figure C.1 Engagement data. 


explains the relationship between each of the tables. The last six data items are not 
part of the data collected from the wargame. They are used for control purposes in the 
program and the names of these fields are identical in the rest of the tables, so thev will 
not be repeated again. The two important control numbers are the slot number and 
the game time. The slot number uniquely identifies each record collected under the 
same game time. The game time distinguishes between like records within the same file. 
Information is collected from the RESA wargame once, sometimes more, during each 
game time or cycle (one minute of game play) for all the files. The values of data items 


within each record may have changed or records may have been added or deleted. 
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Data Item Field Name 


Store Damage 
Hull Damage 


Sam Damage 

Top Side Damage 

Fuel Damage 

OS Identification 
er Remaining 





Figure C.2 Data on ship dynamics. 


Data [tem Field Name 


Name 

Status 

View 

Type 

Attack Index 


Its | 
Missile Hits 


J 
CH 
et 
m. 
O 


ل Gel zÄ AE‏ ت ی 





Figure C.3 Platform unit data. 


Data Item Field Name 


mue 6 
True Longitude 





Figure C.4 Position data. 


All the files are related through the slot number and the game time. The position 
file and platform file match up one-to-one by slot number and game time. This reveals 
the true position of each unit. The remote detection file and platform unit file match 
up one-to-one for game time but the detectee number in the remote detection file is 


matched to the slot number in the unit platform unit file. This identifies the target that 


6l 


Data Item 


+ 0.8195 
+ 2.7799 
20 


Data Item 


is detected. In the unit damage file, the data item “unit” matches to the slot number in 
the platform unit data file under the same game time. This identifies the unit which 
received damage. The last relationship is between the data on ship dynamics and 
platform unit data. These files match one-to-one for slot number and game time to 


identify the appropriate dynamic information for the right unit. 


Field Name 


Apparent Latitude 
Apparent Longitude 
Detectee 





Figure C.5 Remote detection data. 


Field Name 


Time 

Unit 

Base 

Fuel 

Stores 

Samsites 
Sinking 

Weapon Svstems 
Next ۳ 
Aircraft 
Number Devices 
View 

Report Status 
Modifie 

Name Index 
Speed 





Figure C.6 Unit damage data. 
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APPENDIX D 
SEMANTIC DATA MODEL FOR THE DSS C2 WORKSTATION 


DYNAMICS INFORMATION 


description; contains dvnamic data for ships, submarines, shore bases, 
and aircraft flights. 


member attributes: 

Name 

value class: UNIT NAMES 
Store damage 

value class: PERCENTAGE 
Hull. damage 

value class: PERCENTAGE 
Sam damage 

value class: PERCENTAGE 
Topside damage 

value class: PERCENTAGE 
Fuel damage 

value class: PERCENTAGE 
Identification 


description: identifies equipment item attached to unit, 
for example. radar or missile tvpe. 


value class: [ITEM NAME 
multivalued 5 


Remaining 


description: number of equipment items remaining under 
Identification due to operational damages or expenditures. 


value class: NUMBER ITEMS 
multivalued pa 


identifiers: 


Name 
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ACTIVE_UNITS 


description: Contains names, pointers, and other 


| ,7208ھ"‎ ۰ data 
for all active ships, shore bases, aircraft flights, and cruise missiles. 


member attributes: 


Name 
value class: UNIT NAMES 
mandatory 

Status 


description: contains present condition of unit, for example, 
sinking or on station. 


value class: UNIT STATUS 
mandatory 


View 
description: identifies character of unit, for example, hostile. 


value class: DISPOSITION 
mandatory 


Type 


description: identifies kind of unit, for example, submarine 
Or cruise missile. 


value class: TYPE UNIT 
mandatory 


Assigned target of unit 
description: it indicates the target unit is attacking. 


value class: UNIT NAMES 
Bomb hits 


description: contains number of bomb hits a unit received 
during a current game cycle. 


value class: NUMBER EPU 
multivalued me 


Missile hits 


description: contains number of missile hits a unit received 
during a current game cvcle. 


value class: NUMBER EPU 
multivalued 7 


identifiers: 


Name 
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REMOTE_DETECTIONS 
description: contains detected tracks of active units. 
member attributes: 
Apparent_latitude 


value class: POSITION LATITUDE 
mandatory 


comment: must be in degrees. 
Apparent_longitude 


value class; POSITION LONGITUDE 
mandatory 


comment: must be in degrees. 
Name_of_unit_detected 
value class: UNIT NAMES 
identifiers: 


Name_of_unit_detected 


TRUE_POSITION 


description: identifies ground true latitude and longitude of active 
units. 


member attributes: 
True_latitude 
value class: POSITION LATITUDE 
comment: must be in degrees. 
True_longitude 
value class: POSITION_LONGITUDE 
comment: must be in degrees. 
Name_of_unit 


value class: UNIT NAMES 
mandatory 


identifiers: 


Name 
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INFLICTED_DAMAGE 


description: contains damage information relative to ships, aircraft 
and various shore installations. 


member attributes: 
Time of. damage 
value class: MINUTES 
Damaged_unit 


value class: UNIT NAMES 
multivalued ` E 


Base 
description: indicates whether base did or did not receive damage. 
value class: INDICATOR 

Fuel 


description: indicates whether hull or fuel stores did or did not 
receive damage. 


value class: INDICATOR 
Stoves 


description: indicates whether weapon stores did or did not 
receive damage. 


value class: INDICATOR 
Sam, sites 


ar indicates whether SAM sites did or did not receive 
amage. 


value class: INDICATOR 

Sinking 
description: indicates whether a ship is or is not sinking. 
value class: INDICATOR 

Weapon system 


description: indicates whether weapon svstem did or did not 
receive damage. 


value class: INDICATOR 

Aircraft 
description: contains number of damaged parked aircraft. 
value class: PARKED AIRCRAFT 
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Number_devices 


description: contains number of sensor devices that were 
damaged. 


value class: SENSORS DAMAGE 

View 
description: identifies owner of damaged unit, example, hostile. 
value class: DISPOSITION 

Report status 
description: for example, report needed or report sent. 
value class: REPORTING 

Speed 
description: maximum speed of ship after damage. 
value class: MAX SPEED 

identifiers: 


Damage_unit 


ENGAGEMENT_DATA 


description: contains force engagement data for ships, aircraft, and 
cruise missiles which are attacking opposing units. 


member attributes: 
Name of engaging unit 
value class: UNIT NAMES 
mandatorv 
multivaluéd 
Type of. missile. fired 
description: for example, sparrow, phenx. 


value class. TYPE MISSILE 
multivalued - 


Assigned_target_of_missile 
value class: TYPE_UNIT 
Number_of_missiles_fired 


value class: NUMBER_FIRED 
multivalue 
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Probability hit 


description: contains probability of hitting target considering 
the range where missile was fired. 


value class: PERCENTAGE 
Status 


description: contains, present condition of unit, for example, 
proceeding or on guide. 


value class: UNIT STATUS 
mandatory e 


View 


۲ tion: identifies character of attacking unit, example, 
riendly. 


value class; DISPOSITION 
mandatory 


Detected 
description: indicates unit has been detected. 
value class: YES 

Target status 


description: indicates whether target was missed, hit and 
engagement is over, or engaging the target. 


value class: DAMAGED 
multivalued 


Target type 
وت‎ identifies kind of unit being attacked, for example, 
ship. 
value class: TYPE UNIT 
mandatory 
Probability hit target 


description: contains probability that missile will hit target 
given the target’s electronic counter measure capabilities. 


value class: PERCENTAGE 
Unit, latitude 
value class: POSITION LATITUDE 


comment: must be in degrees. 
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Unit longitude 
value class: POSITION LONGITUDE 
comment: must be in degrees. 

Target latitude 
value class: POSITION LATITUDE 
comment: must be in degrees. 

Target longitude 
value class: POSITION LONGITUDE 
comment: must be in degrees. 

identifiers: 


Name of engaging unit 


UNIT. NAMES 


description: contains names of all ships, subs, aircraft, cruise 
missiles and shore stations. 


intercíass connection: subclass of STRINGS where length is less than 
eight characters. 


UNIT. STATUS 


description: contains present condition of each active unit, for 
example, being deleted, proceeding or recovery. 


interclass connection: subclass of STRINGS where format is 
non-negative integer less than 10. 


TYPE_UNIT 


description: identifies kind of unit, for example, surface or shore 
ase. 


interclass connection: subclass of STRINGS where format is a 
positive integer less than 11. 


DISPOSITION 


. 


A a identifies whether unit is neutral, friendly, hostile, 
or unknown. 


interclass connection: subclass of STRINGS where format is a 
positive integer less than 
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NUMBER_EPU 


description: identifies number of explosive power units (EPU) 
received by a unit. 


interclass connection: subclass of STRINGS where format is 
non-negative less than 201. 


MINUTES 
description: identifies game time when unit was damaged. 


interclass connection: subclass of STRINGS where format is 
non-negative integer less 2401. 


INDICATOR 


description: statement indicates whether unit did or did not receive 
any damage. 


interclass connection: subclass of STRINGS where format is 0 or 1. 
PARKED_AIRCRAFT 
description: identifies number of parked aircraft that were damaged. 


interclass connection: subclass of STRINGS where format is 
non-negative integer less than 1001. 


SENSORS_ DAMAGED 
description: indicates number of damaged sensor devices. 


interclass connection: subclass of STRINGS where format is 
non-negative integer less than 25. 


REPORTING 


description: indicates reported status on damaged units, for 
example, report received. 


interclass connection: subclass of STRINGS where format 1s 
non-negative integer less than eight. 


MAX SPEED 


description: indicates maximum speed of ship, in knots, after being 
damaged. 


interclass connection: subclass of STRINGS where format is 
non-negative integer less than 61. 


PERCENTAGE 


interclass connection: subclass of STRINGS where format is a real 
number between or equal to 0 an 
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ITEM NAME 
description: identifies name of equipment item attached to unit. 


interclass connection: subclass of STRINGS where length is 
less than 10 characters. 


NUMBER ITEMS 


description: contains amount of equipment items still operating 
after a unit is damaged. 


interclass connection: subclass of STRINGS where format is 
non-negative integer less than 5000. 


TYPE_MISSILE 


interclass connection: subclass of STRINGS where length is less than 
eight characters. 


NUMBER_FIRED 


description: contains number of missiles fired at a target from one 
unit. 


interclass connection: subclass of STRINGS where format is 
non-negative integer less than 10. 


MES 

description: indicates unit has been detected. 

interclass connection: subclass of STRINGS where format is 0 or 1. 
DAMAGED 


description: indicates if target was missed by a missile, 
hit bv a missile and engagement over, or engaging target. 


interclass connection: subclass of STRINGS where format is 
non-negative integer less than 5. 


POSITION_LATITUDE 
description: indicates latitude of unit in degrees. 


interclass connection: subclass of STRINGS where format is number 
LLMMSS and X 1s a character. 


POSITION LONGITUDE 
description: indicates longitude of unit in degrees. 


interclass connection: subclass of STRINGS where format is number 
LLLM MSS and X 1s a character. 
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